> From: Tim Deegan [mailto:Tim.Deegan@xxxxxxxxxx]
> Sent: Sunday, May 22, 2011 11:14 AM
>
> 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
Let me take one more shot at this, since no one has yet refuted my original
points.
Why do you *need* IR to have a secure Xen w/ TXT? Certainly a DoS is very
undesirable, but that is not really a security issue. Tell me what security
exploits are still possible with the current patches.
If this all revolves around "gut feel" and not actual technical issues, then I
suppose there isn't much more I can say. But the "argument" that without IR
"it seems like we could do more bad things" is purely speculative. Likewise,
the "argument" that "just because only the mitigated attack was presented
doesn't mean that there aren't others possible" is also meaningless--this same
reasoning applies to any attack, and so just because there is one buffer
overflow found (e.g. CVE-2008-3687) do you panic Xen because there could be
others that just haven't been found yet?
If someone can present a security issue that TXT and SW patches cannot
mitigate, then I would agree that it is not possible to secure a system without
IR and it should be forced on. If you can't make this claim then I don't see
how you have a technical basis for your position.
Joe
> 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
|
Home