Re: [Xen-devel] XSA-60 - how to get back to a sane state

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 03.12.13 at 03:21, Andrew Cooper <andrew.cooper3@xxxxxxxxxx> wrote:
> 1) has the basic XSA-60 fixes and some wbinvd()s, which are a
> significant performance issue and insufficient to completely fix the
> problem at hand.  As a result, 1) is the worst possible option to stay
> with as far as Xen is concerned (irrespective of the upcoming 4.4 release).

I should add that another aspect here is the current inconsistency
of the code: In a few places we give the appearance of taking care
of the required flushing, but we don't really do so everywhere, so
whoever is going to read the code in close detail will rightfully say
"this can't be correct". Whereas if we revert the wbinvd()s we're
at least back to a consistent (even if theoretically broken) state.

> 2) will revert us back to the basic XSA-60 with none of the wbinvd()s,
> which fixes the security issue and is no worse than before in terms of a
> correctness-in-the-case-of-uncachable-hvm-domains point of view.

And keep in mind that at present we have no knowledge of guests
actually needing to run with caching disabled - to only known use
case is that of the guest setting its MTRRs (where the specification
requires caching to be disabled, but the OS [as well as correctness]
doesn't really require that).

> 3) as-is is still insufficient to fix the problem in 1), and would
> currently result in a further performance regression.

Hmm, I'm not sure about the performance regression: During the
sole known usage (see above) there shouldn't be any guest
memory writes, and hence the "needs-flushing" flag should rarely
if ever get set.

> FWIW, my vote is for option 2) which will ease the current performance
> regression, in favor of allowing us time to come up with a proper
> solution to the pre-existing problem of Xen and Qemu mappings of a UC
> domain's memory.

Agreed - my preference too is 2 over 3 over 1.

Jan


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