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

[Malcolm Crossley <malcolm.crossley@xxxxxxxxxx>]

On 17/01/13 08:49, Jan Beulich wrote:
> > > > On 16.01.13 at 22:09, Malcolm Crossley <malcolm.crossley@xxxxxxxxxx> wrote:
> > On 16/01/13 13:57, Jan Beulich wrote:
> > > > > > On 16.01.13 at 00:27, Malcolm Crossley <malcolm.crossley@xxxxxxxxxx> 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.



>

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