[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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 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.
> 

This is fair enough. And it is the major reason why I want to make the
shim works for both hvm and pvh in the first place.

I'm more than happy to work with you to make PV-in-HVM work.

> This gives people an immediate solution that does not require major
> changes to their
> underlying infrastructure.
> 

What is your assessment of the completeness of this series? I think
listing what works or what doesn't will have upstream make the decision
better. For example, does migration work? It doesn't mean everything
needs to be complete before we can start merging it but we do want
upstream users to under what would be broken.

> 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.
> 
> If it was entirely my call, I would work on merging HVM shim first,
> get a 4.10 stable release
> cut with it, and then focus on getting PVH shim in place for the 4.11
> release.  I think
> this is the right balance of addressing the short term needs while
> also having the best long
> term solution.

Not my call either. I will wait for security team member and stable tree
maintainers to weight in.

Wei.

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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.