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

[Malcolm Crossley <malcolm.crossley@citrix.com>]

On 17/01/13 08:49, Jan Beulich wrote:
>>>> On 16.01.13 at 22:09, Malcolm Crossley <malcolm.crossley@citrix.com> wrote:
>> On 16/01/13 13:57, Jan Beulich wrote:
>>>>>> On 16.01.13 at 00:27, Malcolm Crossley <malcolm.crossley@citrix.com> wrote:
>>>> +/* 5500/5520/X58 Chipset Interrupt remapping errata, for stepping B-3.
>>>> + * Fixed in stepping C-2. */
>>>> +void __init tylersburg_intremap_quirk(void)
>>>> +{
>>>> +    uint32_t bus, device;
>>>> +    uint8_t rev;
>>>> +
>>>> +    for ( bus = 0; bus < 0x100; bus++ )
>>>> +    {
>>>> +        /* Match on System Management Registers on Device 20 Function 0 */
>>>> +        device = pci_conf_read32(0, bus, 20, 0, PCI_VENDOR_ID);
>>>> +        rev = pci_conf_read8(0, bus, 20, 0, PCI_REVISION_ID);
>>>> +
>>>> +        if ( rev == 0x13 && device == 0x342e8086 )
>>>> +        {
>>>> +            dprintk(XENLOG_INFO VTDPREFIX,
>>>> +                    "Disabling Interrupt Remapping due to Intel 5500/5520/X58 Chipset errata #47, #53\n");
>>>> +            iommu_intremap = 0;
>>> Unless it is guaranteed that no system with this chipset can have
>>> x2APIC, I don't think this is right. For one, this happens way too
>>> late (namely after x2apic_bsp_setup()). And second, if you move
>>> this earlier, such systems with x2APIC pre-enabled won't boot
>>> anymore.
>> After some digging, I discovered that the errata affects chipsets
>> (5520,5500,X58) which don't have IOMMU EIM( Extended Interrupt Mode)
>> support. EIM is required to support x2APIC mode and so this means the
>> chipset can't support x2APIC mode and so we should never see a system
>> with x2APIC enabled.
> Malcolm,
>
> 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.

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.

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




>