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

[Anthony Liguori <anthony@xxxxxxxxxxxxx>]

On Mon, Jan 8, 2018 at 8:30 AM, Wei Liu <wei.liu2@xxxxxxxxxx> wrote:
> 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.

I don't know if migration works.

I know that a wide range of guests work going back to pretty old kernel versions
including XenoLinux.

Dynamic attach/detach of devices work, API driven reboot/shutdown, CPU capping,
SMP, etc.

I think the major features we haven't tested are probably migration,
CPU hotplug,
and ballooning.

Regards,

Anthony Liguori

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