xen-devel
Re: [Xen-devel] [PATCH] VT-d: improve RMRR validity checking
To: |
Pasi Kärkkäinen <pasik@xxxxxx> |
Subject: |
Re: [Xen-devel] [PATCH] VT-d: improve RMRR validity checking |
From: |
Weidong Han <weidong.han@xxxxxxxxx> |
Date: |
Sat, 23 Jan 2010 20:40:10 +0800 |
Cc: |
"xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Noboru Iwamatsu <n_iwamatsu@xxxxxxxxxxxxxx>, "Cihula, Joseph" <joseph.cihula@xxxxxxxxx>, "Kay, Allen M" <allen.m.kay@xxxxxxxxx>, Sander Eikelenboom <linux@xxxxxxxxxxxxxx>, "keir.fraser@xxxxxxxxxxxxx" <keir.fraser@xxxxxxxxxxxxx> |
Delivery-date: |
Sat, 23 Jan 2010 04:40:37 -0800 |
Envelope-to: |
www-data@xxxxxxxxxxxxxxxxxxx |
In-reply-to: |
<20100122123235.GZ2861@xxxxxxxxxxx> |
List-help: |
<mailto:xen-devel-request@lists.xensource.com?subject=help> |
List-id: |
Xen developer discussion <xen-devel.lists.xensource.com> |
List-post: |
<mailto:xen-devel@lists.xensource.com> |
List-subscribe: |
<http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> |
List-unsubscribe: |
<http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> |
References: |
<C77E162B.6FE6%keir.fraser@xxxxxxxxxxxxx> <4B59098B.6000108@xxxxxxxxx> <4B590FA4.4000008@xxxxxxxxxxxxxx> <4B59132B.40607@xxxxxxxxx> <4B59188C.50901@xxxxxxxxxxxxxx> <4B59660F.4000909@xxxxxxxxx> <1098023846.20100122101901@xxxxxxxxxxxxxx> <4B5996CF.9020409@xxxxxxxxx> <20100122123235.GZ2861@xxxxxxxxxxx> |
Sender: |
xen-devel-bounces@xxxxxxxxxxxxxxxxxxx |
User-agent: |
Thunderbird 2.0.0.21 (Windows/20090302) |
Pasi Kärkkäinen wrote:
On Fri, Jan 22, 2010 at 08:15:11PM +0800, Weidong Han wrote:
Sander Eikelenboom wrote:
Hello Weidong,
Wouldn't it be more clear to add an option to iommu= for this case ?
if iommu=on,..,..,security
With the security option specified:
-it would be most strict in it's checks, since enforcing security with the
iommu requires that as you have pointed out.
-warn,fail or panic incase it can't enable all to enforce the security.
iommu=force is for security. It does as you described above. So I think
"security" option is not necessary.
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 task is not
security, but making as much of vt-d working to keep the passthrough
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
the default iommu=1 works like iommu=force if BIOS is correct. But in
fact we encountered some buggy BIOS, and then we added some workarounds
to make VT-d still be enabled, or warn and disable VT-d if the issue is
regarded as invalid and cannot be workarounded. These workarounds make
Xen more defensive to VT-d BIOS issues. The panic only occurs when
operating VT-d hardware fails, because it means the hardware is possibly
malfunctional.
In short, default iommu=1 can workaround known VT-d BIOS issues we
observed till now, while iommu=force ensures best security provided by
VT-d.
So the default iommu=1 might be insecure? And iommu=force is always secure?
To me "force" sounds like it makes it work always, no matter if it's secure or
not..
The "security" here means the protection provided VT-d. The main
difference between them is iommu=force tries to enable all VT-d units in
any case, if any VT-d unit cannot enabled, it will quit Xen booting
(panic), thus it guarantees security provided by VT-d. while when
iommu=1, in order to workaround some BIOS issues, it will ignore some
invalid DRHDs, or disable whole VT-d to keep Xen work without VT-d.
Regards,
Weidong
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
<Prev in Thread] |
Current Thread |
[Next in Thread>
|
- Re: [Xen-devel] [PATCH] VT-d: improve RMRR validity checking, (continued)
- Re: [Xen-devel] [PATCH] VT-d: improve RMRR validity checking, Sander Eikelenboom
- Re: [Xen-devel] [PATCH] VT-d: improve RMRR validity checking, Keir Fraser
- Re: [Xen-devel] [PATCH] VT-d: improve RMRR validity checking, Weidong Han
- Re: [Xen-devel] [PATCH] VT-d: improve RMRR validity checking, Noboru Iwamatsu
- Re: [Xen-devel] [PATCH] VT-d: improve RMRR validity checking, Weidong Han
- Re: [Xen-devel] [PATCH] VT-d: improve RMRR validity checking, Noboru Iwamatsu
- Re: [Xen-devel] [PATCH] VT-d: improve RMRR validity checking, Weidong Han
- Re: [Xen-devel] [PATCH] VT-d: improve RMRR validity checking, Sander Eikelenboom
- Re: [Xen-devel] [PATCH] VT-d: improve RMRR validity checking, Weidong Han
- Re: [Xen-devel] [PATCH] VT-d: improve RMRR validity checking, Pasi Kärkkäinen
- Re: [Xen-devel] [PATCH] VT-d: improve RMRR validity checking,
Weidong Han <=
- Re: [Xen-devel] [PATCH] VT-d: improve RMRR validity checking, Pasi Kärkkäinen
- Re: [Xen-devel] [PATCH] VT-d: improve RMRR validity checking, Sander Eikelenboom
- Re: [Xen-devel] [PATCH] VT-d: improve RMRR validity checking, documenting boot options, Pasi Kärkkäinen
- RE: [Xen-devel] [PATCH] VT-d: improve RMRR validity checking, documenting boot options, Stephen Spector
- Documentation Xen-hypervisor and Dom0 xen-related boot options (was Re: [Xen-devel] [PATCH] VT-d: improve RMRR validity checking, documenting boot options), Sander Eikelenboom
- RE: Documentation Xen-hypervisor and Dom0 xen-related boot options (was Re: [Xen-devel] [PATCH] VT-d: improve RMRR validity checking, documenting boot options), Stephen Spector
- Re: Documentation Xen-hypervisor and Dom0 xen-related boot options (was Re: [Xen-devel] [PATCH] VT-d: improve RMRR validity checking, documenting boot options), Pasi Kärkkäinen
- Re: [Xen-devel] [PATCH] VT-d: improve RMRR validity checking, Noboru Iwamatsu
- Re: [Xen-devel] [PATCH] VT-d: improve RMRR validity checking, Weidong Han
- Re: [Xen-devel] [PATCH] VT-d: improve RMRR validity checking, Sander Eikelenboom
|
|
|