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..
-- Pasi
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home