|
|
|
|
|
|
|
|
|
|
xen-devel
RE: [Xen-devel] Xen security advisory CVE-2011-1898 - VT-d (PCI passthr
> From: Ian Campbell [mailto:Ian.Campbell@xxxxxxxxxxxxx]
> 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
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
<Prev in Thread] |
Current Thread |
[Next in Thread>
|
- RE: [Xen-devel] Xen security advisory CVE-2011-1898 - VT-d (PCI passthrough) MSI, Jan Beulich
- RE: [Xen-devel] Xen security advisory CVE-2011-1898 - VT-d (PCI passthrough) MSI, Cihula, Joseph
- RE: [Xen-devel] Xen security advisory CVE-2011-1898 - VT-d (PCI passthrough) MSI, Ian Campbell
- RE: [Xen-devel] Xen security advisory CVE-2011-1898 - VT-d (PCI passthrough) MSI,
Cihula, Joseph <=
- Re: [Xen-devel] Xen security advisory CVE-2011-1898 - VT-d (PCI passthrough) MSI, Tim Deegan
- RE: [Xen-devel] Xen security advisory CVE-2011-1898 - VT-d (PCI passthrough) MSI, Cihula, Joseph
- Re: [Xen-devel] Xen security advisory CVE-2011-1898 - VT-d (PCI passthrough) MSI, Tim Deegan
- RE: [Xen-devel] Xen security advisory CVE-2011-1898 - VT-d (PCI passthrough) MSI, Cihula, Joseph
- Re: [Xen-devel] Xen security advisory CVE-2011-1898 - VT-d (PCI passthrough) MSI, Tim Deegan
- RE: [Xen-devel] Xen security advisory CVE-2011-1898 - VT-d (PCI passthrough) MSI, Ian Jackson
- RE: [Xen-devel] Xen security advisory CVE-2011-1898 - VT-d (PCI passthrough) MSI, Cihula, Joseph
- RE: [Xen-devel] Xen security advisory CVE-2011-1898 - VT-d (PCI passthrough) MSI [and 2 more messages], Ian Jackson
- Re: [Xen-devel] Xen security advisory CVE-2011-1898 - VT-d (PCI passthrough) MSI, Alan Cox
- Re: [Xen-devel] Xen security advisory CVE-2011-1898 - VT-d (PCI passthrough) MSI, Ian Jackson
|
|
|
|
|