Re: [Xen-devel] [PATCH 00/22] Vixen: A PV-in-HVM shim

[Matt Wilson <msw@xxxxxxxx>]

On Sat, Jan 06, 2018 at 11:50:46PM +0000, Andrew Cooper wrote:
> On 06/01/2018 22:54, Anthony Liguori wrote:
> > Please note the Xen page table configuration fundamental to the
> > current PV ABI makes it impossible for an operating system to mitigate
> > CVE-2017-5754 through mechanisms like Kernel Page Table Isolation
> > (KPTI).  In order for an operating system to mitigate CVE-2017-5754 it
> > must run directly in a HVM or PVH domU.
> 
> Its a little more complicated than this, but I suppose is worth pointing
> out.
> 
> A 64bit PV guest kernel cannot, of its own accord, protect itself
> against SP3/Meltdown.  This is due to the shared nature/responsibility
> of pagetables between the PV guest kernel and Xen.
> 
> What the Vixen/PV-shim plan does is isolate the guest sufficiently that
> any SP3 attacks can't read data belonging to other guests on the host.
> 
> An SP3/Meltdown mitigation can only come from having Xen change the way
> it uses pagetables, and my 44-patch prerequisite series serves to
> demonstrate that this seems impractical with the existing ABI.

I'm not sure we're saying anything different than you are.

> > This series is very similar to the PVH series posted by Wei and we
> > have been discussing how to merge efforts.  We were hoping to have
> > more time to work this out.  I am posting this because I'm fairly
> > confident that this series is complete (all PV instances in EC2 are
> > using this) and others might find it useful.  I also wanted to have
> > more of a discussion about the best way to merge and some of the
> > differences in designs.
> 
> Some ad hoc thoughts so far:
> 
> * Upstream, we need to take the PV-Shim side of domid handling. 
> Unilaterally using dom1 is fine for server-virt infrastructure where
> guests only ever talk to dom0, but isn't fine if you've got domains
> which are communicating directly (e.g. with libvchan).  This is very
> minor in the grand scheme of things though.

Agreed. Handling domU to domU communication will be more
complicated. Passing through a different domid isn't too hard, and
that should handle most of it. We were attempting to make this as
simple as possible...

> * I do prefer the Vixen side of startup, where we describe rather more
> clearly what is going on.  I never got around to stea^W borrowing this
> for PV-shim.
> 
> * Whatever eventual version gets in upstream, it is important that it
> HVM and PVH capable for backwards and forwards compatibility.  Again,
> this doesn't appear to be too complicated to arrange in practice.  For
> reference, what is the oldest version of Xen you need to target here? 
> (The pre-console-ring observation puts it quite old)

3.4.mumble.

> * For PV-shim, we took the approach of making the domU neither
> privileged nor the hardware domain.  While I expect this throws up a
> different set of issues, I think it is a cleaner approach overall.
> 
> I'm sure there are areas I've missed, but this is hopefully a start.

Thanks for the quick feedback, and for all the help along the way.

--msw

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel