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

[Tim Deegan <Tim.Deegan@xxxxxxxxxx>]

At 17:02 +0100 on 20 May (1305910924), Cihula, Joseph wrote:
> > At 21:48 +0100 on 19 May (1305841716), Cihula, Joseph wrote:
> > > So how would the user (or installation SW) specify to use the best
> > > (IOMMU) security available on the platform?
> > 
> > iommu=on.  That pretty much lines up with the current meaining.
> 
> 'iommu=on' is really "*try* to use the best but it's OK if you can't",
> as it will allow execution to continue even if enabling the supported
> features fails.  'force' is really this with the caveat that execution
> won't continue if it fails to enable them.

Yes, exactly.  By extension, "on" turns on interrupt remapping if it's
there but "it's OK if you can't"; "force" requires it.  I don't
understand why you would want iommu=force to crash if the IOMMU is
missing but not if it's insecure.

> But as I said, if you're writing a Xen installer and you want to
> *ensure* that Xen uses the HW features of the system, are you going to
> make some table that tells whether any given system supports IR so
> that you know which ones to add ',nointremap' to? 

This is exactly the behaviour we already have if you don't have an iommu
at all.  The installer already needs to figure out whether there's an
IOMMU, or make it optional.

If you really want to rely on TXT and Xen to mutuallly secure each
other, then as far as I can see you _need_ an interrupt remapper in all
your supported hardware.  That being the case, iommu=force should
enforce that requirement.  If you're willing to settle for best-effort,
iommu=on already does that.

Tim.

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

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel