From mboxrd@z Thu Jan 1 00:00:00 1970 From: Weidong Han Subject: Re: [PATCH] VT-d: improve RMRR validity checking Date: Sat, 23 Jan 2010 20:40:10 +0800 Message-ID: <4B5AEE2A.5040100@intel.com> References: <4B59098B.6000108@intel.com> <4B590FA4.4000008@jp.fujitsu.com> <4B59132B.40607@intel.com> <4B59188C.50901@jp.fujitsu.com> <4B59660F.4000909@intel.com> <1098023846.20100122101901@eikelenboom.it> <4B5996CF.9020409@intel.com> <20100122123235.GZ2861@reaktio.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <20100122123235.GZ2861@reaktio.net> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: =?ISO-8859-1?Q?Pasi_K=E4rkk=E4inen?= Cc: "xen-devel@lists.xensource.com" , Noboru Iwamatsu , "Cihula, Joseph" , "Kay, Allen M" , Sander Eikelenboom , "keir.fraser@eu.citrix.com" List-Id: xen-devel@lists.xenproject.org Pasi K=E4rkk=E4inen wrote: > On Fri, Jan 22, 2010 at 08:15:11PM +0800, Weidong Han wrote: > =20 >> Sander Eikelenboom wrote: >> =20 >>> Hello Weidong, >>> >>> Wouldn't it be more clear to add an option to iommu=3D for this case = ? >>> >>> if iommu=3Don,..,..,security >>> >>> With the security option specified: >>> -it would be most strict in it's checks, since enforcing securit= y with the iommu requires that as you have pointed out. >>> -warn,fail or panic incase it can't enable all to enforce the se= curity. >>> =20 >>> =20 >> iommu=3Dforce is for security. It does as you described above. So I th= ink =20 >> "security" option is not necessary. >> =20 >>> Without the security option specified (default) >>> - it tries to work as with the security option specified >>> - but incase of problems makes the assumption the iommu's main t= ask is not security, but making as much of vt-d working to keep the passt= hrough functionality >>> - it will only warn, that you will lose the security part, that = it would be wise to let your bios be fixed, and not making it panic >>> - and keep vt-d enabled >>> >>> =20 >>> =20 >> the default iommu=3D1 works like iommu=3Dforce if BIOS is correct. But= in =20 >> fact we encountered some buggy BIOS, and then we added some workaround= s =20 >> to make VT-d still be enabled, or warn and disable VT-d if the issue = is =20 >> regarded as invalid and cannot be workarounded. These workarounds make= =20 >> Xen more defensive to VT-d BIOS issues. The panic only occurs when =20 >> operating VT-d hardware fails, because it means the hardware is possib= ly =20 >> malfunctional. >> >> In short, default iommu=3D1 can workaround known VT-d BIOS issues we =20 >> observed till now, while iommu=3Dforce ensures best security provided = by=20 >> VT-d. >> >> =20 > > So the default iommu=3D1 might be insecure? And iommu=3Dforce is always= secure?=20 > > To me "force" sounds like it makes it work always, no matter if it's se= cure or not.. > =20 The "security" here means the protection provided VT-d. The main=20 difference between them is iommu=3Dforce tries to enable all VT-d units i= n=20 any case, if any VT-d unit cannot enabled, it will quit Xen booting=20 (panic), thus it guarantees security provided by VT-d. while when=20 iommu=3D1, in order to workaround some BIOS issues, it will ignore some=20 invalid DRHDs, or disable whole VT-d to keep Xen work without VT-d.=20 Regards, Weidong