Re: [Xen-devel] [PATCH] VTD/Intremap: Disable Intremap on Chipset 5500/5520/X58 due to errata

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 17.01.13 at 11:02, Malcolm Crossley <malcolm.crossley@xxxxxxxxxx> wrote:
> On 17/01/13 08:49, Jan Beulich wrote:
>> I still don't feel well with this making a small security hole bigger
>> (the erratum to me mainly means that with lost interrupts we
>> might observe systems hangs in the worst case, or maybe
>> data corruption if recovery code in the OSes doesn't work well).
>> Whereas with interrupt remapping disabled passthrough
>> becomes inherently insecure (and the host vulnerable to guest
>> attacks).
>>
>> So the question really is whether, rather than disabling interrupt
>> remapping, disabling the IOMMU as a whole wouldn't be the
>> better (read: more secure) workaround.
>
> The patch is just achieving the same effect in Xen as the BIOS 
> workaround recommended in the Intel errata document.

But there's a difference nevertheless. If firmware disables
something, it's identical to hardware not having the capability.
Whereas if software disables functionality and opens/widens
a security hole by doing so, that's a flaw that would
subsequently require an advisory+fix on its own.

> I also don't like the making the security hole bigger but I think we are 
> making an Xen IOMMU support policy change if we disable the IOMMU 
> support when interrupt remapping is not supported.

Why do you think so? The behavior we currently have causes the
system to not boot if "iommu=force", including the case where
interrupt remapping didn't get enabled but was intended to be (i.e.
no "iommu=no-intremap"). And without "iommu=force" we make it
impossible to assign devices to HVM guests (i.e. preventing security
issues). Between functionality and security, I think security has to
win by default (but an override ought to be possible).

> Additionally, I believe that if we make this policy change then we will 
> disable Xen IOMMU support for the Intel 3100/3200 chipset series.

Because of what?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel