Re: [Xen-devel] [PATCH 0/2] AMD IOMMU: XSA-36 follow ups

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Fri, 2013-02-08 at 16:48 +0000, Jan Beulich wrote:
> >>> On 08.02.13 at 15:29, Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx> wrote:
> 
> > ----- JBeulich@xxxxxxxx wrote:
> > 
> >> >>> On 06.02.13 at 14:04, "Jan Beulich" <JBeulich@xxxxxxxx> wrote:
> >> > A regression was reported on a class of broken firmware that c/s
> >> > 26517:601139e2b0db didn't consider, leading to a boot time crash.
> >> 
> >> After some more thought on this and the comments we got
> >> regarding disabling the IOMMU in this situation altogether making
> >> things worse instead of better, I came to the conclusion that we
> >> can actually restrict the action in affected cases to just disabling
> >> interrupt remapping. That doesn't make the situation worse than
> >> prior to the XSA-36 fixes (where interrupt remapping didn't really
> >> protect domains from one another), but allows at least DMA
> >> isolation to still be utilized. Patch 3/2 below/attached.
> > 
> > But now users who don't examine log messages may not realize 
> > that interupt remapping is disabled and therefore the system can be
> > affected by XSA-36.
> 
> Yes. We need to balance these against one another - I see pros
> and cons in both (and I don't mind dropping this additional patch
> if we collectively come to the conclusion that the way it is now -
> with the one earlier fix - is the better state). So I'm really
> interested in others' opinions.

Given the infrastructure currently available for dealing with these
things in a more fine-grained/less heavy-handed manner (i.e. not much)
and in the context of security advisories (where obviousness of the
patch is a very useful property and where we are effectively
highlighting the issue to the world) I think it is reasonable to be
fairly aggressive in our handling of systems which don't provide the
necessary security properties.

Most of these sorts of issues naturally only arise as part of a security
vulnerability but if someone wanted to implement more fine grained
control after the fact that would also seem reasonable.

If we had pre-existing better infrastructure for determining controlling
things at runtime, including informing the user and allowing for
overrides, which could be tweaked with one or two lines in a security
fix then it would seem reasonable to use them up front.

Somebody would need to figure out what that actually means and implement
it as part of the normal development process, since we obviously don't
want to do it next time we are under the cosh of an impending security
advisory.

Ian.


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