Quantcast

Xen security advisory CVE-2011-1898 - VT-d (PCI passthrough) MSI

classic Classic list List threaded Threaded
38 messages Options
12
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Xen security advisory CVE-2011-1898 - VT-d (PCI passthrough) MSI

Ian Jackson-2
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

             Xen security advisory CVE-2011-1898
           VT-d (PCI passthrough) MSI trap injection

ISSUE DESCRIPTION
=================

Intel VT-d chipsets without interrupt remapping do not prevent a guest
which owns a PCI device from using DMA to generate MSI interrupts by
writing to the interrupt injection registers.  This can be exploited
to inject traps and gain control of the host.


VULNERABLE SYSTEMS
==================

You are not vulnerable if you do not use "PCI passthrough".  That is,
if you do not pass actual PCI devices (eg, graphics and network
controllers) through to guests, for use by PCI device drivers in the
guest.

In Xen with xend/xm or with xl this would be enabled by the "pci="
option in the domain config file, or by using the "xl pci-attach" or
"xm pci-attach" management command; if you do not use these features,
you are not vulnerable.

You are not vulnerable if you are using PCI passthrough, but are not
using Intel VT-d or AMD-Vi (aka "iommu") to attempt to prevent escape
by guest DMA.  This is because in such a configuration, privilege
escalation and denial of service are possible by guests anyway, and
the present issue does not make the situation any worse.

You are vulnerable if you use Intel VT-d to pass PCI devices through
to untrusted guests, unless your have interrupt remapping supported
and enabled.  This is the case whether you are using Xen, KVM, or
another virtualisation system.

Interrupt remapping is available in newer Intel VT-d chipsets.


IMPACT
======

A guest given a PCI passthrough device can escalate its privilege and
gain control of the whole system.


MITIGATION AND RESOLUTION
=========================

No complete software fix is available but we understand that Intel has
addressed this issue with newer hardware.

We believe a patch along the lines of the one attached can be applied
to Xen to reduce the impact to a denial of service.  Even with such a
patch, a guest can still cause a complete system crash or resource
starvation.

Upgrading to recent hardware that is interrupt remapping capable will
resolve the remaining denial of service issues.  Support for interrupt
remapping, when the hardware is capable, is present in all currently
maintained versions of Xen.

On such recent hardware, when passing pci devices through to untrusted
guests, we recommend the use of the "iommu=required" Xen command line
boot option and the second atttached patch, to avoid unknowingly
booting into a vulnerable configuration.


REFERENCES
==========

Thanks to Rafal Wojtczuk and Joanna Rutkowska of Invisible Things Lab
for bringing this issue to our attention.  Their paper on the attack
will soon be available from Invisible Things Lab, at
www.invisiblethingslab.com.

Information regarding chipset versions and interrupt remapping support
should be available from Intel; please use your usual support and
security response channels at Intel.

We believe that this vulnerability exists with all virtualisation
systems which aim to support passing pci devices through to
untrusted guests, on the affected Intel hardware.  If you are using
a hypervisor other than Xen please refer to your hypervisor's usual
security support and advisory release channels.


PATCHES
=======

The first patch is intended to reduce the impact from full privilege
escalation to denial of service.
 Filename: 00-block-msis-on-trap-vectors
 SHA1: 0fcc1914714c228e98b3e84597e06cb5de09003c
 SHA256: 998e8d5632ee6ad92f52796fe94923f9c38096c5adf2ca74209a6792436ea1e9

The second patch is intended to ensure that when Xen boots with
"iommu=required" it will also insist that interrupt remapping is
supported and enabled.  It arranges that booting with that option on
vulnerable hardware will fail, rather than appearing to succeed but
actually being vulnerable to guests.
 Filename: intremap05033.patch
 SHA1: 1cd26adc5ead0c07b67bf354f03164235d67395c
 SHA256: 7f8c7d95d33bbd5c4f25671b380e70020fda1ba6cb50b67e59131fa8e59c1c66

Unfortunately we have not been able to test either patch.  Both will
be applied to xen-unstable very soon.  We also intend to provide
backports in the supported released Xen trees.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iJwEAQECAAYFAk3L5JUACgkQQz2i6ICVfYMh9wP/S/D3xN48bKBM2sBNuO08Hqhy
0ViFGdgZGs3p5EbRCIRTGe6YZonh8oIJi/JSxevd5WD7gDeV+8Dfr4in/gKXWThI
6kyJCzMZdJeB4ecJsX64sKS9pShJT39J1RAoeLeEGiPahO1Id6UySyF23xoF0R0E
7RpPPfG5lxS0xwdQO4M=
=yfWW
-----END PGP SIGNATURE-----


_______________________________________________
Xen-devel mailing list
[hidden email]
http://lists.xensource.com/xen-devel

00-block-msis-on-trap-vectors (5K) Download Attachment
intremap05033.patch (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Xen security advisory CVE-2011-1898 - VT-d (PCI passthrough) MSI

Ian Jackson-2
I wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>              Xen security advisory CVE-2011-1898
>            VT-d (PCI passthrough) MSI trap injection
...

> The first patch is intended to reduce the impact from full privilege
> escalation to denial of service.
>  Filename: 00-block-msis-on-trap-vectors
>  SHA1: 0fcc1914714c228e98b3e84597e06cb5de09003c
>  SHA256: 998e8d5632ee6ad92f52796fe94923f9c38096c5adf2ca74209a6792436ea1e9
>
> The second patch is intended to ensure that when Xen boots with
> "iommu=required" it will also insist that interrupt remapping is
> supported and enabled.  It arranges that booting with that option on
> vulnerable hardware will fail, rather than appearing to succeed but
> actually being vulnerable to guests.
>  Filename: intremap05033.patch
>  SHA1: 1cd26adc5ead0c07b67bf354f03164235d67395c
>  SHA256: 7f8c7d95d33bbd5c4f25671b380e70020fda1ba6cb50b67e59131fa8e59c1c66

These patches should probably be applied to xen-unstable now.

Ian.

_______________________________________________
Xen-devel mailing list
[hidden email]
http://lists.xensource.com/xen-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Xen security advisory CVE-2011-1898 - VT-d (PCI passthrough) MSI

Jan Beulich
In reply to this post by Ian Jackson-2
>>> On 12.05.11 at 15:48, Ian Jackson <[hidden email]> wrote:
> Intel VT-d chipsets without interrupt remapping do not prevent a guest
> which owns a PCI device from using DMA to generate MSI interrupts by
> writing to the interrupt injection registers.  This can be exploited
> to inject traps and gain control of the host.

Isn't that (or at least can't that be) prevented with DMA remapping?

> The first patch is intended to reduce the impact from full privilege
> escalation to denial of service.
>  Filename: 00-block-msis-on-trap-vectors
>  SHA1: 0fcc1914714c228e98b3e84597e06cb5de09003c
>  SHA256: 998e8d5632ee6ad92f52796fe94923f9c38096c5adf2ca74209a6792436ea1e9

You modify only 64-bit and only VT-d code here. While I know you
don't care much for it, doing the same for 32-bit would seem trivial.

As to AMD's IOMMU, it may well be that interrupt re-mapping isn't
optional in the hardware (albeit it can be disabled on the command
line, though that's the admin's security risk then), but the code
having BUG_ON()s on failed allocations and those allocations
happening in table parsing callbacks doesn't really make this
explicit (for me at least) on the first glance.

Finally, wouldn't killing all guests that potentially could have caused
the problem be a better measure than bringing down the host?

Jan


_______________________________________________
Xen-devel mailing list
[hidden email]
http://lists.xensource.com/xen-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Xen security advisory CVE-2011-1898 - VT-d (PCI passthrough) MSI

Ian Campbell-10
In reply to this post by Ian Jackson-2
On Thu, 2011-05-12 at 14:48 +0100, Ian Jackson wrote:
> The second patch is intended to ensure that when Xen boots with
> "iommu=required" it will also insist that interrupt remapping is
> supported and enabled.  It arranges that booting with that option on
> vulnerable hardware will fail, rather than appearing to succeed but
> actually being vulnerable to guests.
>  Filename: intremap05033.patch
>  SHA1: 1cd26adc5ead0c07b67bf354f03164235d67395c
>  SHA256:
> 7f8c7d95d33bbd5c4f25671b380e70020fda1ba6cb50b67e59131fa8e59c1c66

This patch became 23338:9751bc49639e but it is not clear that it goes
far enough since it appears to rely on TXT or similar since it
implicitly trusts the contents of DMAR (via the call to
platform_supports_intremap()).

I think we should go further and try to be safe by default, even if TXT
is not present. (I don't actually have a VT-d capable machine handy to
properly test this).

8<--------------------------------

# HG changeset patch
# User Ian Campbell <[hidden email]>
# Date 1305282251 -3600
# Node ID cfffebdedd0b1f1f3f23f60df269f50f7320226b
# Parent  48d68a57f3e8885366478b418e77b043f73dcb2c
vt-d: [CVE-2011-1898] refuse to boot with VT-d IOMMU enabled without interupt remapping

CVE-2011-1898 shows that IOMMU is vulnerable to privilege escalation attacks if
Interrupt Remapping is not available.

23364:9751bc49639e tries to ensure that Interrupt Remapping is always enabled
if iommu=required is passed on the command line. However this relies on being
able to trust the DMAR and therefore requires TXT, as well as the user adding
that particular option.

This patch causes the hypervisor to refuse to boot with VT-d IOMMU enabled
unless Interrupt Remapping is also available. This will prevent unwitting users
of older hardware from running in an insecure mode when they may think they are
secure because they have an IOMMU. It will also prevent a malicious guest from
tricking a system which does support IOMMU into booting without it.

Users with pre-Interrupt Remapping hardware who accept the risks are still able to
pass iommu=no-intremap on the command line in order to revert to previous
behaviour.

Signed-off-by: Ian Campbell <[hidden email]>

diff -r 48d68a57f3e8 -r cfffebdedd0b xen/drivers/passthrough/vtd/iommu.c
--- a/xen/drivers/passthrough/vtd/iommu.c Fri May 13 11:10:13 2011 +0100
+++ b/xen/drivers/passthrough/vtd/iommu.c Fri May 13 11:24:11 2011 +0100
@@ -1965,32 +1965,17 @@ static int init_vtd_hw(void)
         for ( apic = 0; apic < nr_ioapics; apic++ )
         {
             if ( ioapic_to_iommu(IO_APIC_ID(apic)) == NULL )
-            {
-                iommu_intremap = 0;
-                dprintk(XENLOG_ERR VTDPREFIX,
-                    "ioapic_to_iommu: ioapic 0x%x (id: 0x%x) is NULL! "
-                    "Will not try to enable Interrupt Remapping.\n",
-                    apic, IO_APIC_ID(apic));
-                if ( force_iommu )
-                    panic("intremap remapping failed to enable with iommu=required/force in grub\n");
-                break;
-            }
+                panic(VTDPREFIX
+                      "ioapic_to_iommu: ioapic 0x%x (id: 0x%x) is NULL! "
+                      "Unable to enable Interrupt Remapping.\n",
+                      apic, IO_APIC_ID(apic));
         }
-    }
-    if ( iommu_intremap )
-    {
+
         for_each_drhd_unit ( drhd )
         {
             iommu = drhd->iommu;
             if ( enable_intremap(iommu, 0) != 0 )
-            {
-                dprintk(XENLOG_WARNING VTDPREFIX,
-                        "Interrupt Remapping not enabled\n");
-
-                if ( force_iommu && platform_supports_intremap() )
-                    panic("intremap remapping failed to enable with iommu=required/force in grub\n");
-                break;
-            }
+                panic(VTDPREFIX "Failed to enable Interrupt Remapping\n");
         }
     }
 
@@ -2066,7 +2051,7 @@ int __init intel_vtd_setup(void)
             iommu_qinval = 0;
 
         if ( iommu_intremap && !ecap_intr_remap(iommu->ecap) )
-            iommu_intremap = 0;
+            panic(VTDPREFIX "IOMMU: hardware does not support Interrupt Remapping");
 
         if ( !vtd_ept_page_compatible(iommu) )
             iommu_hap_pt_share = FALSE;
@@ -2081,11 +2066,8 @@ int __init intel_vtd_setup(void)
     }
 
     if ( !iommu_qinval && iommu_intremap )
-    {
-        iommu_intremap = 0;
-        dprintk(XENLOG_WARNING VTDPREFIX, "Interrupt Remapping disabled "
+        panic(XENLOG_WARNING "Interrupt Remapping disabled "
             "since Queued Invalidation isn't supported or enabled.\n");
-    }
 
 #define P(p,s) printk("Intel VT-d %s %senabled.\n", s, (p)? "" : "not ")
     P(iommu_snoop, "Snoop Control");



_______________________________________________
Xen-devel mailing list
[hidden email]
http://lists.xensource.com/xen-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Xen security advisory CVE-2011-1898 - VT-d (PCI passthrough) MSI

Joanna Rutkowska-2
In reply to this post by Jan Beulich
On 05/13/11 10:08, Jan Beulich wrote:
>>>> On 12.05.11 at 15:48, Ian Jackson <[hidden email]> wrote:
>> Intel VT-d chipsets without interrupt remapping do not prevent a guest
>> which owns a PCI device from using DMA to generate MSI interrupts by
>> writing to the interrupt injection registers.  This can be exploited
>> to inject traps and gain control of the host.
>
> Isn't that (or at least can't that be) prevented with DMA remapping?
>

No. That's sort of the key point here, and the reason why IR hardware is
required.

>> The first patch is intended to reduce the impact from full privilege
>> escalation to denial of service.
>>  Filename: 00-block-msis-on-trap-vectors
>>  SHA1: 0fcc1914714c228e98b3e84597e06cb5de09003c
>>  SHA256: 998e8d5632ee6ad92f52796fe94923f9c38096c5adf2ca74209a6792436ea1e9
>
> You modify only 64-bit and only VT-d code here. While I know you
> don't care much for it, doing the same for 32-bit would seem trivial.
>
> As to AMD's IOMMU, it may well be that interrupt re-mapping isn't
> optional in the hardware (albeit it can be disabled on the command
> line, though that's the admin's security risk then), but the code
> having BUG_ON()s on failed allocations and those allocations
> happening in table parsing callbacks doesn't really make this
> explicit (for me at least) on the first glance.
>
> Finally, wouldn't killing all guests that potentially could have caused
> the problem be a better measure than bringing down the host?
>
Killing the guest might no longer be enough, because the guest might
have already programmed the device to keep sending malicious MSIs. So,
panic()ing the whole VMM seems like a safer choice. Keep in mind that on
a non-IR hardware there are probably many other ways for the malicious
driver domain to cause global DoS. (In fact, my impression is that most
people regarded IR as an anti-DoS mechanism, and I believe our paper is
the first to show that the problems were far worse than possible DoS.)

joanna.

> Jan
>
>
> _______________________________________________
> Xen-devel mailing list
> [hidden email]
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
[hidden email]
http://lists.xensource.com/xen-devel

signature.asc (529 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Xen security advisory CVE-2011-1898 - VT-d (PCI passthrough) MSI

Ian Campbell-10
On Fri, 2011-05-13 at 12:08 +0100, Joanna Rutkowska wrote:
> On 05/13/11 10:08, Jan Beulich wrote:

> > Finally, wouldn't killing all guests that potentially could have caused
> > the problem be a better measure than bringing down the host?
> >
>
> Killing the guest might no longer be enough, because the guest might
> have already programmed the device to keep sending malicious MSIs.

Is it even possible to know which guest triggered the MSI, or is the
best you can do the set of all guests with an MSI capable device passed
through?

Ian.


_______________________________________________
Xen-devel mailing list
[hidden email]
http://lists.xensource.com/xen-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Xen security advisory CVE-2011-1898 - VT-d (PCI passthrough) MSI

Joanna Rutkowska-2
On 05/13/11 13:11, Ian Campbell wrote:

> On Fri, 2011-05-13 at 12:08 +0100, Joanna Rutkowska wrote:
>> On 05/13/11 10:08, Jan Beulich wrote:
>
>>> Finally, wouldn't killing all guests that potentially could have caused
>>> the problem be a better measure than bringing down the host?
>>>
>>
>> Killing the guest might no longer be enough, because the guest might
>> have already programmed the device to keep sending malicious MSIs.
>
> Is it even possible to know which guest triggered the MSI, or is the
> best you can do the set of all guests with an MSI capable device passed
> through?
>
Ah, probably you're right -- if we have more than one driver domain,
then I think LAPIC would not tell us which device genrated the MSI.

In fact it's not really correct to assume that it must have been a guest
with a "MSI capable device" -- note that we don't trigger the MSI via
the official MSI triggering mechanism.

joanna.


_______________________________________________
Xen-devel mailing list
[hidden email]
http://lists.xensource.com/xen-devel

signature.asc (529 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Xen security advisory CVE-2011-1898 - VT-d (PCI passthrough) MSI

Jan Beulich
In reply to this post by Joanna Rutkowska-2
>>> On 13.05.11 at 13:08, Joanna Rutkowska <[hidden email]> wrote:
> On 05/13/11 10:08, Jan Beulich wrote:
>>>>> On 12.05.11 at 15:48, Ian Jackson <[hidden email]> wrote:
>>> Intel VT-d chipsets without interrupt remapping do not prevent a guest
>>> which owns a PCI device from using DMA to generate MSI interrupts by
>>> writing to the interrupt injection registers.  This can be exploited
>>> to inject traps and gain control of the host.
>>
>> Isn't that (or at least can't that be) prevented with DMA remapping?
>>
>
> No. That's sort of the key point here, and the reason why IR hardware is
> required.

So are you saying that the memory transaction triggering the MSI is
indistinguishable from any other DMA operation? Implying that the
guest must be granted access to the page containing the MSI
address the device is to write to? If so, the changes done as a
result of your report are only addressing a (very?) small subset of
bad things such a guest could do.

>>> The first patch is intended to reduce the impact from full privilege
>>> escalation to denial of service.
>>>  Filename: 00-block-msis-on-trap-vectors
>>>  SHA1: 0fcc1914714c228e98b3e84597e06cb5de09003c
>>>  SHA256: 998e8d5632ee6ad92f52796fe94923f9c38096c5adf2ca74209a6792436ea1e9
>>
>> You modify only 64-bit and only VT-d code here. While I know you
>> don't care much for it, doing the same for 32-bit would seem trivial.
>>
>> As to AMD's IOMMU, it may well be that interrupt re-mapping isn't
>> optional in the hardware (albeit it can be disabled on the command
>> line, though that's the admin's security risk then), but the code
>> having BUG_ON()s on failed allocations and those allocations
>> happening in table parsing callbacks doesn't really make this
>> explicit (for me at least) on the first glance.
>>
>> Finally, wouldn't killing all guests that potentially could have caused
>> the problem be a better measure than bringing down the host?
>>
>
> Killing the guest might no longer be enough, because the guest might
> have already programmed the device to keep sending malicious MSIs. So,

Obviously, resetting the devices should be part of killing such guests.

Jan

> panic()ing the whole VMM seems like a safer choice. Keep in mind that on
> a non-IR hardware there are probably many other ways for the malicious
> driver domain to cause global DoS. (In fact, my impression is that most
> people regarded IR as an anti-DoS mechanism, and I believe our paper is
> the first to show that the problems were far worse than possible DoS.)
>
> joanna.



_______________________________________________
Xen-devel mailing list
[hidden email]
http://lists.xensource.com/xen-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Xen security advisory CVE-2011-1898 - VT-d (PCI passthrough) MSI

Jan Beulich
In reply to this post by Joanna Rutkowska-2
>>> On 13.05.11 at 13:20, Joanna Rutkowska <[hidden email]> wrote:
> On 05/13/11 13:11, Ian Campbell wrote:
>> On Fri, 2011-05-13 at 12:08 +0100, Joanna Rutkowska wrote:
>>> On 05/13/11 10:08, Jan Beulich wrote:
>>
>>>> Finally, wouldn't killing all guests that potentially could have caused
>>>> the problem be a better measure than bringing down the host?
>>>>
>>>
>>> Killing the guest might no longer be enough, because the guest might
>>> have already programmed the device to keep sending malicious MSIs.
>>
>> Is it even possible to know which guest triggered the MSI, or is the
>> best you can do the set of all guests with an MSI capable device passed
>> through?
>>
>
> Ah, probably you're right -- if we have more than one driver domain,
> then I think LAPIC would not tell us which device genrated the MSI.

That's why I wrote "killing all guests that potentially could have ...".

> In fact it's not really correct to assume that it must have been a guest
> with a "MSI capable device" -- note that we don't trigger the MSI via
> the official MSI triggering mechanism.

You lost me here. Neither am I clear about what "non-official"
triggering mechanism we use, nor can I see how a guest without
any MSI-capable device would be able to trigger the problem.

And even if things are as you say, it would still seem better to kill
all guests with *any* passed through device, than bring down the
entire host (there could e.g. be dozens of innocent pv guests and
only a single hvm one that has a problematic device assigned).

Jan


_______________________________________________
Xen-devel mailing list
[hidden email]
http://lists.xensource.com/xen-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Xen security advisory CVE-2011-1898 - VT-d (PCI passthrough) MSI

Tim Deegan-4
In reply to this post by Jan Beulich
At 13:29 +0100 on 13 May (1305293351), Jan Beulich wrote:
> So are you saying that the memory transaction triggering the MSI is
> indistinguishable from any other DMA operation? Implying that the
> guest must be granted access to the page containing the MSI
> address the device is to write to? If so, the changes done as a
> result of your report are only addressing a (very?) small subset of
> bad things such a guest could do.

Yes, and yes.  The only real fix is for the hardware to do interrupt
remapping, and the hypervisor to enforce it.  The patches that go with
the advisory only reduce a full exploit to a DoS (and so, whether you
kill all device-owning domains or the whole hypervisor is pretty much
moot).

Cheers,

Tim.

--
Tim Deegan <[hidden email]>
Principal Software Engineer, Xen Platform Team
Citrix Systems UK Ltd.  (Company #02937203, SL9 0BG)

_______________________________________________
Xen-devel mailing list
[hidden email]
http://lists.xensource.com/xen-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Xen security advisory CVE-2011-1898 - VT-d (PCI passthrough) MSI

Joanna Rutkowska-2
In reply to this post by Ian Jackson-2
Our paper describing the attacks can be now downloaded from here:

http://www.invisiblethingslab.com/itl/Resources.html

(Sorry the actual link contains spaces and would likely by unclickable
if I pasted it here).

Cheers,
joanna.

On 05/12/11 15:48, Ian Jackson wrote:

>              Xen security advisory CVE-2011-1898
>            VT-d (PCI passthrough) MSI trap injection
>
> ISSUE DESCRIPTION
> =================
>
> Intel VT-d chipsets without interrupt remapping do not prevent a guest
> which owns a PCI device from using DMA to generate MSI interrupts by
> writing to the interrupt injection registers.  This can be exploited
> to inject traps and gain control of the host.
>
>
> VULNERABLE SYSTEMS
> ==================
>
> You are not vulnerable if you do not use "PCI passthrough".  That is,
> if you do not pass actual PCI devices (eg, graphics and network
> controllers) through to guests, for use by PCI device drivers in the
> guest.
>
> In Xen with xend/xm or with xl this would be enabled by the "pci="
> option in the domain config file, or by using the "xl pci-attach" or
> "xm pci-attach" management command; if you do not use these features,
> you are not vulnerable.
>
> You are not vulnerable if you are using PCI passthrough, but are not
> using Intel VT-d or AMD-Vi (aka "iommu") to attempt to prevent escape
> by guest DMA.  This is because in such a configuration, privilege
> escalation and denial of service are possible by guests anyway, and
> the present issue does not make the situation any worse.
>
> You are vulnerable if you use Intel VT-d to pass PCI devices through
> to untrusted guests, unless your have interrupt remapping supported
> and enabled.  This is the case whether you are using Xen, KVM, or
> another virtualisation system.
>
> Interrupt remapping is available in newer Intel VT-d chipsets.
>
>
> IMPACT
> ======
>
> A guest given a PCI passthrough device can escalate its privilege and
> gain control of the whole system.
>
>
> MITIGATION AND RESOLUTION
> =========================
>
> No complete software fix is available but we understand that Intel has
> addressed this issue with newer hardware.
>
> We believe a patch along the lines of the one attached can be applied
> to Xen to reduce the impact to a denial of service.  Even with such a
> patch, a guest can still cause a complete system crash or resource
> starvation.
>
> Upgrading to recent hardware that is interrupt remapping capable will
> resolve the remaining denial of service issues.  Support for interrupt
> remapping, when the hardware is capable, is present in all currently
> maintained versions of Xen.
>
> On such recent hardware, when passing pci devices through to untrusted
> guests, we recommend the use of the "iommu=required" Xen command line
> boot option and the second atttached patch, to avoid unknowingly
> booting into a vulnerable configuration.
>
>
> REFERENCES
> ==========
>
> Thanks to Rafal Wojtczuk and Joanna Rutkowska of Invisible Things Lab
> for bringing this issue to our attention.  Their paper on the attack
> will soon be available from Invisible Things Lab, at
> www.invisiblethingslab.com.
>
> Information regarding chipset versions and interrupt remapping support
> should be available from Intel; please use your usual support and
> security response channels at Intel.
>
> We believe that this vulnerability exists with all virtualisation
> systems which aim to support passing pci devices through to
> untrusted guests, on the affected Intel hardware.  If you are using
> a hypervisor other than Xen please refer to your hypervisor's usual
> security support and advisory release channels.
>
>
> PATCHES
> =======
>
> The first patch is intended to reduce the impact from full privilege
> escalation to denial of service.
>  Filename: 00-block-msis-on-trap-vectors
>  SHA1: 0fcc1914714c228e98b3e84597e06cb5de09003c
>  SHA256: 998e8d5632ee6ad92f52796fe94923f9c38096c5adf2ca74209a6792436ea1e9
>
> The second patch is intended to ensure that when Xen boots with
> "iommu=required" it will also insist that interrupt remapping is
> supported and enabled.  It arranges that booting with that option on
> vulnerable hardware will fail, rather than appearing to succeed but
> actually being vulnerable to guests.
>  Filename: intremap05033.patch
>  SHA1: 1cd26adc5ead0c07b67bf354f03164235d67395c
>  SHA256: 7f8c7d95d33bbd5c4f25671b380e70020fda1ba6cb50b67e59131fa8e59c1c66
>
> Unfortunately we have not been able to test either patch.  Both will
> be applied to xen-unstable very soon.  We also intend to provide
> backports in the supported released Xen trees.
>
_______________________________________________
Xen-devel mailing list
[hidden email]
http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
[hidden email]
http://lists.xensource.com/xen-devel

signature.asc (529 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Xen security advisory CVE-2011-1898 - VT-d (PCI passthrough) MSI

Joanna Rutkowska-2
On 05/13/11 19:32, Joanna Rutkowska wrote:
> Our paper describing the attacks can be now downloaded from here:
>
> http://www.invisiblethingslab.com/itl/Resources.html
>
> (Sorry the actual link contains spaces and would likely by unclickable
> if I pasted it here).
>
or perhaps not:

http://www.invisiblethingslab.com/resources/2011/Software%20Attacks%20on%20Intel%20VT-d.pdf


_______________________________________________
Xen-devel mailing list
[hidden email]
http://lists.xensource.com/xen-devel

signature.asc (529 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: Xen security advisory CVE-2011-1898 - VT-d (PCI passthrough) MSI

Cihula, Joseph
In reply to this post by Ian Campbell-10
> From: [hidden email] [mailto:[hidden email]] On

> Behalf Of Ian Campbell
> Sent: Friday, May 13, 2011 3:25 AM
>
> On Thu, 2011-05-12 at 14:48 +0100, Ian Jackson wrote:
> > The second patch is intended to ensure that when Xen boots with
> > "iommu=required" it will also insist that interrupt remapping is
> > supported and enabled.  It arranges that booting with that option on
> > vulnerable hardware will fail, rather than appearing to succeed but
> > actually being vulnerable to guests.
> >  Filename: intremap05033.patch
> >  SHA1: 1cd26adc5ead0c07b67bf354f03164235d67395c
> >  SHA256:
> > 7f8c7d95d33bbd5c4f25671b380e70020fda1ba6cb50b67e59131fa8e59c1c66
>
> This patch became 23338:9751bc49639e but it is not clear that it goes far enough since it appears
> to rely on TXT or similar since it implicitly trusts the contents of DMAR (via the call to
> platform_supports_intremap()).
>
> I think we should go further and try to be safe by default, even if TXT is not present. (I don't
> actually have a VT-d capable machine handy to properly test this).
>
> 8<--------------------------------
>
> # HG changeset patch
> # User Ian Campbell <[hidden email]> # Date 1305282251 -3600 # Node ID
> cfffebdedd0b1f1f3f23f60df269f50f7320226b
> # Parent  48d68a57f3e8885366478b418e77b043f73dcb2c
> vt-d: [CVE-2011-1898] refuse to boot with VT-d IOMMU enabled without interupt remapping
>
> CVE-2011-1898 shows that IOMMU is vulnerable to privilege escalation attacks if Interrupt
> Remapping is not available.
>
> 23364:9751bc49639e tries to ensure that Interrupt Remapping is always enabled if iommu=required is
> passed on the command line. However this relies on being able to trust the DMAR and therefore
> requires TXT, as well as the user adding that particular option.
>
> This patch causes the hypervisor to refuse to boot with VT-d IOMMU enabled unless Interrupt
> Remapping is also available. This will prevent unwitting users of older hardware from running in
> an insecure mode when they may think they are secure because they have an IOMMU. It will also
> prevent a malicious guest from tricking a system which does support IOMMU into booting without it.
>
> Users with pre-Interrupt Remapping hardware who accept the risks are still able to pass iommu=no-
> intremap on the command line in order to revert to previous behaviour.
>
> Signed-off-by: Ian Campbell <[hidden email]>
>
> diff -r 48d68a57f3e8 -r cfffebdedd0b xen/drivers/passthrough/vtd/iommu.c
> --- a/xen/drivers/passthrough/vtd/iommu.c Fri May 13 11:10:13 2011 +0100
> +++ b/xen/drivers/passthrough/vtd/iommu.c Fri May 13 11:24:11 2011 +0100
> @@ -1965,32 +1965,17 @@ static int init_vtd_hw(void)
>          for ( apic = 0; apic < nr_ioapics; apic++ )
>          {
>              if ( ioapic_to_iommu(IO_APIC_ID(apic)) == NULL )
> -            {
> -                iommu_intremap = 0;
> -                dprintk(XENLOG_ERR VTDPREFIX,
> -                    "ioapic_to_iommu: ioapic 0x%x (id: 0x%x) is NULL! "
> -                    "Will not try to enable Interrupt Remapping.\n",
> -                    apic, IO_APIC_ID(apic));
> -                if ( force_iommu )
> -                    panic("intremap remapping failed to enable with iommu=required/force in
> grub\n");
> -                break;
> -            }
> +                panic(VTDPREFIX
> +                      "ioapic_to_iommu: ioapic 0x%x (id: 0x%x) is NULL! "
> +                      "Unable to enable Interrupt Remapping.\n",
> +                      apic, IO_APIC_ID(apic));
>          }
> -    }
I'm OK with this, as the user can always specify "no-intremap" if they really want to boot anyway, and the "force" behavior will be the same.

> -    if ( iommu_intremap )
> -    {
> +

Unless I'm misreading it, this will prevent users from specifying "no-intremap" to disable the use of IR.  Why would you keep the 'if ( iommu_intremap )' on the previous code block but remove it here?

>          for_each_drhd_unit ( drhd )
>          {
>              iommu = drhd->iommu;
>              if ( enable_intremap(iommu, 0) != 0 )
> -            {
> -                dprintk(XENLOG_WARNING VTDPREFIX,
> -                        "Interrupt Remapping not enabled\n");
> -
> -                if ( force_iommu && platform_supports_intremap() )
> -                    panic("intremap remapping failed to enable with iommu=required/force in
> grub\n");
> -                break;
> -            }
> +                panic(VTDPREFIX "Failed to enable Interrupt
> + Remapping\n");
>          }
>      }
>
> @@ -2066,7 +2051,7 @@ int __init intel_vtd_setup(void)
>              iommu_qinval = 0;
>
>          if ( iommu_intremap && !ecap_intr_remap(iommu->ecap) )
> -            iommu_intremap = 0;
> +            panic(VTDPREFIX "IOMMU: hardware does not support Interrupt
> + Remapping");
>
>          if ( !vtd_ept_page_compatible(iommu) )
>              iommu_hap_pt_share = FALSE; @@ -2081,11 +2066,8 @@ int __init intel_vtd_setup(void)
>      }
>
>      if ( !iommu_qinval && iommu_intremap )
> -    {
> -        iommu_intremap = 0;
> -        dprintk(XENLOG_WARNING VTDPREFIX, "Interrupt Remapping disabled "
> +        panic(XENLOG_WARNING "Interrupt Remapping disabled "
>              "since Queued Invalidation isn't supported or enabled.\n");
> -    }
>
>  #define P(p,s) printk("Intel VT-d %s %senabled.\n", s, (p)? "" : "not ")
>      P(iommu_snoop, "Snoop Control");

I disagree with these parts as well.

These changes would say that if the user wants IOMMU enabled that the system must also support IR.  Let me list several issues with such an approach:

This may actually weaken security rather than increase it.  Let's face it, most users won't buy new HW just because the latest version of their SW breaks on their current HW (were it only so easy ;-) ).  So those users will be forced to either turn off IOMMU or not upgrade Xen.  In the former case, they will lose the ability to separate the hypervisor from domains (even dom0 is not equally privileged to the hypervisor) as well as having decreased robustness from driver bugs/FW bugs/etc.  In the latter case, they will not get any of the other security and feature fixes from newer versions of Xen.

MSI support has been on systems before there was even an IOMMU capability.  Why does adding IOMMU make these systems suddenly insecure?  All of the same uses that existed before IOMMU are still valid even with it--why disallow them (see above as to why forcing user to turn off IOMMU is bad).

IOMMU adds security capabilities.  IR adds additional security capabilities.  IOMMU allows for fully isolating the hypervisor from domains even if the domains control DMA devices.  It helps to protect against buggy drivers or device FW by limiting the areas such bugs can affect to just the DMA data buffers.  IOMMU, in conjunction with Intel(R) Trusted Execution Technology (TXT), provides DMA protection through the entire launch process and into runtime.  This is all true regardless of the presence of IR.  IR adds the ability to prevent DoS attacks by untrusted domains with assigned DMA devices, malicious device FW, etc.  This is incremental--not all or nothing.

The 00-block-msis-on-trap-vectors patch (esp. in conjunction with TXT) prevents all known security exploits of MSI misuse.  Might there still be vulnerabilities to MSI--yes, and when they're found they will be fixed.  If we find a code injection bug that would have been prevented by XD/NX, do we disallow running on systems without XD/NX capability just because there might be more such bugs--no, we fix the ones we know about and will fix others as they are found.

If you really want to fail to run insecurely, here is the patch you need:
diff -r f9bb0bbea7c2 xen/arch/x86/boot/head.S
--- a/xen/arch/x86/boot/head.S  Thu May 12 16:42:54 2011 +0100
+++ b/xen/arch/x86/boot/head.S  Mon May 16 14:40:50 2011 -0700
@@ -20,7 +20,7 @@
 #define BOOT_PSEUDORM_DS 0x0028

 ENTRY(start)
-        jmp     __start
+        hlt

         .align 4
 /*** MULTIBOOT HEADER ****/

Joe

_______________________________________________
Xen-devel mailing list
[hidden email]
http://lists.xensource.com/xen-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: Xen security advisory CVE-2011-1898 - VT-d (PCI passthrough) MSI

Jan Beulich
In reply to this post by Ian Jackson-2
>>> "Cihula, Joseph" <[hidden email]> 05/16/11 11:34 PM >>>
>IOMMU adds security capabilities. IR adds additional security capabilities. IOMMU allows for fully isolating the hypervisor
>from domains even if the domains control DMA devices. It helps to protect against buggy drivers or device FW by limiting
>the areas such bugs can affect to just the DMA data buffers. IOMMU, in conjunction with Intel(R) Trusted Execution
>Technology (TXT), provides DMA protection through the entire launch process and into runtime. This is all true regardless
>of the presence of IR. IR adds the ability to prevent DoS attacks by untrusted domains with assigned DMA devices,
>malicious device FW, etc. This is incremental--not all or nothing.

I think this is the problem - you're saying things like "fully isolating" and "regardless of the presence of IR", while the paper they made accessible meanwhile makes clear that neither is true. Thus the mere presence of DMA protection creates false expectation of customers - without IR (and with MSI supported by the system, not necessarily the device passed through) there's no way for isolation to become complete (actually, with non-MSI-capable devices or by disallowing MSI altogether on capable ones, depending of whether MSI writes bypass the IOMMU or simply get 1:1 translated, it could be possible to make this secure).

>The 00-block-msis-on-trap-vectors patch (esp. in conjunction with TXT) prevents all known security exploits of MSI misuse.

All? Not really, just a very small subset, and only partially. The SIPI one is perhaps the worst case (not prevented by this patch), but being able to send SMI or NMI perhaps isn't much better (as long as we're considering DoS attacks to also be a problem, which at least I do, and in which case said patch only converts from one [worse] to another ["better"] evil).

Jan

_______________________________________________
Xen-devel mailing list
[hidden email]
http://lists.xensource.com/xen-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: Xen security advisory CVE-2011-1898 - VT-d (PCI passthrough) MSI

Cihula, Joseph

From: Jan Beulich [mailto:[hidden email]]
Sent: Tuesday, May 17, 2011 12:43 AM
To: [hidden email]; Cihula, Joseph
Cc: [hidden email]
Subject: RE: [Xen-devel] Xen security advisory CVE-2011-1898 - VT-d (PCI passthrough) MSI

 

>>> "Cihula, Joseph" <[hidden email]> 05/16/11 11:34 PM >>>
>IOMMU adds security capabilities. IR adds additional security capabilities. IOMMU allows for fully isolating the hypervisor
>from domains even if the domains control DMA devices. It helps to protect against buggy drivers or device FW by limiting
>the areas such bugs can affect to just the DMA data buffers. IOMMU, in conjunction with Intel(R) Trusted Execution
>Technology (TXT), provides DMA protection through the entire launch process and into runtime. This is all true regardless
>of the presence of IR. IR adds the ability to prevent DoS attacks by untrusted domains with assigned DMA devices,
>malicious device FW, etc. This is incremental--not all or nothing.

I think this is the problem - you're saying things like "fully isolating" and "regardless of the presence of IR", while the paper they made accessible

[JC]  I will admit to being a little overreaching in use of that adverb; let’s remove “fully” and my statement still stands.

 

meanwhile makes clear that neither is true. Thus the mere presence of DMA protection creates false expectation of customers - without IR (and with MSI supported by the system, not necessarily the device passed through) there's no way for isolation to become complete (actually, with non-MSI-capable devices or by disallowing MSI altogether on capable ones, depending of whether MSI writes bypass the IOMMU or simply get 1:1 translated, it could be possible to make this secure).

[JC]  The expectations of users will depend on the features advertised and how they are implemented in the SW solutions that use IOMMU.  Such SW should not be advertising DoS protection if devices are assigned to untrusted domains on systems without IR.  Just like it should not advertise that on systems without IOMMU.  (Note that the DMA protection of IOMMU should prevent most/all accidental/buggy behaviors; MSI DoS would almost certainly have to be due to malicious code.)

 

>The 00-block-msis-on-trap-vectors patch (esp. in conjunction with TXT) prevents all known security exploits of MSI misuse.

All? Not really, just a very small subset, and only partially. The SIPI one is perhaps the worst case (not prevented by this patch), but being able to send SMI or NMI perhaps isn't much better (as long as we're considering DoS attacks to also be a problem, which at least I do, and in which case said patch only converts from one [worse] to another ["better"] evil).
[JC]  I didn’t say “all exploits”—I said all *known* exploits, and that is correct.  The SIPI attack, which isn’t known to be exploitable, is prevented by TXT (hence the “esp. in conjunction with TXT” in my statement).  Naturally, DoS attacks are problematic from a reliability perspective but they were not what I was referring to with the term “security exploit”.

 

I still fail to see an argument that justifies panic’ing Xen when IOMMU is enabled on non-IR systems.  And I don’t think the way to manage customer expectations is through SW freezing.

 


Jan


_______________________________________________
Xen-devel mailing list
[hidden email]
http://lists.xensource.com/xen-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: Xen security advisory CVE-2011-1898 - VT-d (PCI passthrough) MSI

Ian Campbell-12
In reply to this post by Cihula, Joseph
On Mon, 2011-05-16 at 22:34 +0100, Cihula, Joseph wrote:
> > -    if ( iommu_intremap )
> > -    {
> > +
>
> Unless I'm misreading it, this will prevent users from specifying
> "no-intremap" to disable the use of IR.

That wasn't my intention.

> Why would you keep the 'if ( iommu_intremap )' on the previous code
> block but remove it here?

To be honest this change was a little bit unrelated, which was naughty
of me. I saw:
        if ( iommu_intremap ) {
                THING A
        }
        if ( iommu_intremap ) {
                THING B
        }
and changed it to
        if (iommu_intremap ) {
                THING A
                THING B
        }

Is there some subtlety to this code path that I've missed?

Ian.


_______________________________________________
Xen-devel mailing list
[hidden email]
http://lists.xensource.com/xen-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: Xen security advisory CVE-2011-1898 - VT-d (PCI passthrough) MSI

Ian Campbell-12
In reply to this post by Cihula, Joseph
On Tue, 2011-05-17 at 23:52 +0100, Cihula, Joseph wrote:
> I still fail to see an argument that justifies panic’ing Xen when
> IOMMU is enabled on non-IR systems.  And I don’t think the way to
> manage customer expectations is through SW freezing.

Leaving the iommu=on behaviour the same as today but making iommu=force
require IR (with an explicit opt-out a la iommu=force,no-intremap) is
possibly sufficient (and considerably less harsh than the previous
proposal).

Perhaps something like the following?

# HG changeset patch
# Parent 3db330334e3512a5326bbed4881718a63eec171a
diff -r 3db330334e35 -r 975cd3817d7a xen/drivers/passthrough/vtd/iommu.c
--- a/xen/drivers/passthrough/vtd/iommu.c Fri May 13 14:41:18 2011 +0100
+++ b/xen/drivers/passthrough/vtd/iommu.c Mon May 16 11:37:41 2011 +0100
@@ -1987,7 +1987,7 @@ static int init_vtd_hw(void)
                 dprintk(XENLOG_WARNING VTDPREFIX,
                         "Interrupt Remapping not enabled\n");
 
-                if ( force_iommu && platform_supports_intremap() )
+                if ( force_iommu )
                     panic("intremap remapping failed to enable with iommu=required/force in grub\n");
                 break;
             }

I also considered
+               if ( force_iommy && ( !tboot_in_measured_env() || platform_supports_intremap() )

but I trusting the result of tboot_in_measured_env() in the non-TXT case
seems a bit silly.

Ian.


_______________________________________________
Xen-devel mailing list
[hidden email]
http://lists.xensource.com/xen-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Xen security advisory CVE-2011-1898 - VT-d (PCI passthrough) MSI

Keir Fraser-5
In reply to this post by Ian Campbell-12
On 18/05/2011 09:53, "Ian Campbell" <[hidden email]> wrote:

> On Mon, 2011-05-16 at 22:34 +0100, Cihula, Joseph wrote:
>>> -    if ( iommu_intremap )
>>> -    {
>>> +
>>
>> Unless I'm misreading it, this will prevent users from specifying
>> "no-intremap" to disable the use of IR.
>
> That wasn't my intention.
>
>> Why would you keep the 'if ( iommu_intremap )' on the previous code
>> block but remove it here?
>
> To be honest this change was a little bit unrelated, which was naughty
> of me. I saw:
> if ( iommu_intremap ) {
> THING A
> }
> if ( iommu_intremap ) {
> THING B
> }
> and changed it to
> if (iommu_intremap ) {
> THING A
> THING B
> }
>
> Is there some subtlety to this code path that I've missed?

'THING A' conditionally clears iommu_intremap.

 -- Keir

> Ian.
>
>
> _______________________________________________
> Xen-devel mailing list
> [hidden email]
> http://lists.xensource.com/xen-devel



_______________________________________________
Xen-devel mailing list
[hidden email]
http://lists.xensource.com/xen-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Xen security advisory CVE-2011-1898 - VT-d (PCI passthrough) MSI

Ian Campbell-12
On Wed, 2011-05-18 at 11:03 +0100, Keir Fraser wrote:

> On 18/05/2011 09:53, "Ian Campbell" <[hidden email]> wrote:
>
> > On Mon, 2011-05-16 at 22:34 +0100, Cihula, Joseph wrote:
> >>> -    if ( iommu_intremap )
> >>> -    {
> >>> +
> >>
> >> Unless I'm misreading it, this will prevent users from specifying
> >> "no-intremap" to disable the use of IR.
> >
> > That wasn't my intention.
> >
> >> Why would you keep the 'if ( iommu_intremap )' on the previous code
> >> block but remove it here?
> >
> > To be honest this change was a little bit unrelated, which was naughty
> > of me. I saw:
> > if ( iommu_intremap ) {
> > THING A
> > }
> > if ( iommu_intremap ) {
> > THING B
> > }
> > and changed it to
> > if (iommu_intremap ) {
> > THING A
> > THING B
> > }
> >
> > Is there some subtlety to this code path that I've missed?
>
> 'THING A' conditionally clears iommu_intremap.

Right, but in this patch I was switching those to panic()s, so maybe not
such an unrelated change after all.

Anyway, I don't think this patch is going to fly so it doesn't really
matter.

Ian.



_______________________________________________
Xen-devel mailing list
[hidden email]
http://lists.xensource.com/xen-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: Xen security advisory CVE-2011-1898 - VT-d (PCI passthrough) MSI

Cihula, Joseph
In reply to this post by Ian Campbell-12
> From: Ian Campbell [mailto:[hidden email]]

> Sent: Wednesday, May 18, 2011 1:54 AM
>
> On Tue, 2011-05-17 at 23:52 +0100, Cihula, Joseph wrote:
> > I still fail to see an argument that justifies panic’ing Xen when
> > IOMMU is enabled on non-IR systems.  And I don’t think the way to
> > manage customer expectations is through SW freezing.
>
> Leaving the iommu=on behaviour the same as today but making iommu=force require IR (with an
> explicit opt-out a la iommu=force,no-intremap) is possibly sufficient (and considerably less harsh
> than the previous proposal).
>
> Perhaps something like the following?
>
> # HG changeset patch
> # Parent 3db330334e3512a5326bbed4881718a63eec171a
> diff -r 3db330334e35 -r 975cd3817d7a xen/drivers/passthrough/vtd/iommu.c
> --- a/xen/drivers/passthrough/vtd/iommu.c Fri May 13 14:41:18 2011 +0100
> +++ b/xen/drivers/passthrough/vtd/iommu.c Mon May 16 11:37:41 2011 +0100
> @@ -1987,7 +1987,7 @@ static int init_vtd_hw(void)
>                  dprintk(XENLOG_WARNING VTDPREFIX,
>                          "Interrupt Remapping not enabled\n");
>
> -                if ( force_iommu && platform_supports_intremap() )
> +                if ( force_iommu )
>                      panic("intremap remapping failed to enable with iommu=required/force in
> grub\n");
>                  break;
>              }
So how would the user (or installation SW) specify to use the best (IOMMU) security available on the platform?  It looks like this change would again either mean giving up on forcing IOMMU or having to alter the command line based on knowing what the platform's IR capability is.

I think that it is desirable to have an option that says "use the best IOMMU security supported by the platform", and "force" does that right now.

Since what you're really trying to do is to always force IR to be on, why not just create a new option "force-intr"?  Or if your goal is to force the use of the best security capabilities available on any platform, and fail on the rest, then define a new option for that.

>
> I also considered
> +               if ( force_iommy && ( !tboot_in_measured_env() ||
> + platform_supports_intremap() )
>
> but I trusting the result of tboot_in_measured_env() in the non-TXT case seems a bit silly.

_______________________________________________
Xen-devel mailing list
[hidden email]
http://lists.xensource.com/xen-devel
12
Loading...