Re: [Xen-devel] Xen Security Advisory 154 (CVE-2016-2270) - x86: inconsistent cachability flags on guest mappings

[David Woodhouse <dwmw2@xxxxxxxxxxxxx>]

On Wed, 2017-01-25 at 07:21 -0700, Jan Beulich wrote:
> Note the difference between "contains" and "overlaps".

Oh, that makes more sense; thanks.

> > And then there's a 'if (direct_mmio) return UC;' further down which
> > looks like it'd do the right thing for the use case I'm actually
> > testing. I may see if I can construct a straw man patch, but I'm kind
> > of unfamiliar with this code so it should be taken with a large pinch
> > of salt...
>
> If there wasn't INVALID_MFN to be taken care of, the !mfn_valid()
> check could simply move down, and be combined with the
> direct_mmio one.

I'll see what I can come up with.

> > WC vs. UC. But it would be good to have a definitive answer from Intel
> > and AMD about whether it's safe.
>
> Well, in the context of this XSA we've asked both of them, and iirc
> we've got a vague reply from Intel and none from AMD. In fact we
> did defer the XSA for quite a bit waiting for any useful feedback.
> To AMD's advantage I'd like to add though that iirc they're a little
> more clear in their PM about the specific question of UC and WC
> you raise: They group the various cacheabilities into two groups
> (cacheable and uncacheable) and require there to only not be
> any mixture between groups. Iirc Intel's somewhat vague reply
> allowed us to conclude we're likely safe that way on their side too.

That's useful information; thanks. Coupled with the empirical testing
and the fact that we're already "violating" the recommendation of the
Intel SDM by allowing a mixture of memory types on RAM pages, I think
that's probably sufficient to conclude that it's OK to permit this.

Attachment: smime.p7s
Description: S/MIME cryptographic signature

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