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

[Anthony Liguori <anthony@xxxxxxxxxxxxx>]

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

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.

Regards,

Anthony Liguori

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

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