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

[Roger Pau Monné <roger.pau@xxxxxxxxxx>]

On Mon, Jan 08, 2018 at 08:02:07AM -0800, Anthony Liguori wrote:
> On Mon, Jan 8, 2018 at 4:11 AM, Roger Pau Monné <roger.pau@xxxxxxxxxx> wrote:
> > On Mon, Jan 08, 2018 at 11:54:57AM +0000, Wei Liu wrote:
> >> Hi Anthony
> >>
> >> On Sat, Jan 06, 2018 at 02:54:15PM -0800, Anthony Liguori wrote:
> >> > From: Anthony Liguori <aliguori@xxxxxxxxxx>
> >> >
> >> > CVE-2017-5754 is problematic for paravirtualized x86 domUs because it
> >> > appears to be very difficult to isolate the hypervisor's page tables
> >> > from PV domUs while maintaining ABI compatibility.  Instead of trying
> >> > to make a KPTI-like approach work for Xen PV, it seems reasonable to
> >> > run a copy of Xen within an HVM (or PVH) domU to provide backwards
> >> > compatibility with guests as mentioned in XSA-254 [1].
> >> >
> >> > This patch series adds a new mode to Xen called Vixen (Virtualized
> >> > Xen) which provides a PV-compatible interface while gaining
> >> > CVE-2017-5754 protection for the host provided by hardware
> >> > virtualization.  Vixen supports running a single unprivileged PV
> >> > domain (a dom1) that is constructed by the dom0 domain builder.
> >> >
> >> > 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.
> >> >
> >> > 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.
> >> >
> >> > This series is also available at:
> >> >
> >> >  git clone https://github.com/aliguori/xen.git vixen-upstream-v1
> >>
> >> I do want to make the shim be able to run in both pvh and hvm mode
> >> (which doesn't seem to be too hard in practice).
> >
> > AFAIK the pv-shim code will already work in HVM mode. It's just that
> > booting the pv-shim in HVM mode requires that you install the shim
> > inside of the guest and then boot it using grub or a similar loader
> > that can do multiboot.
> 
> I'm happy to work on either approach.  I just want to get something
> merged to have
> an upstream solution to this issue.  I think this particular CVE for
> Xen PV is the worst
> of this batch of issues so I'm super eager on getting a solution
> straightened out.  I'd
> really like to hear from others on what the right approach should be
> and I'll work on
> whatever the consensus is.

I agree it's important to get something merged or in a decent shape in
order to solve/mitigate this issue, and likely ASAP.

> I think PVH is a good long term solution but I think it's a poor short
> term solution.
> PVH isn't widely deployed so it's asking people to upgrade their
> infrastructure to a
> very new version of Xen.  It also requires tools changes which means
> that even if
> you are on a newer version of Xen, you still have to upgrade.  The
> patch series is
> also pretty big which means I suspect people will need to wait to 4.11 at 
> best.
> 
> OTOH, the HVM version of the series requires no tools changes and works on Xen
> versions going back to 3.4 (at least).  What this means practically
> speaking is that
> if it were merged, we can tell people that they can solve this problem
> by building the
> HVM shim and modifying their launch config to boot from an ISO or
> something similar.

The only difference here is that vixen is capable of using more event
channel injection mechanisms, whether the pv-shim is limited to
HVMOP_set_evtchn_upcall_vector ATM. Apart from that pv-shim code
should work fine inside of an HVM container.

> This gives people an immediate solution that does not require major
> changes to their
> underlying infrastructure.
> 
> The series now is also reasonably contained and small enough that
> IMHO, it could go
> into the stable tree.  That means that once merged, we could cut a
> stable release giving
> people an official release that could be used for this purpose.

It's also important to note that vixen series are also smaller because
it supports a much more limited set of features. The pv-shim code
supports migration, vcpu hotplug/unplug (the vcpu is actually
plugged/unplugged from the shim itself) and memory ballooning.

IMHO merging a sub-set of the pv-shim work in order to get a set of
functionality similar to the one offered by vixen should probe
easier.

Roger.

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