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

[Anthony Liguori <anthony@xxxxxxxxxxxxx>]

On Sat, Jan 6, 2018 at 3:50 PM, Andrew Cooper <andrew.cooper3@xxxxxxxxxx> wrote:
> On 06/01/2018 22:54, 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)
>
> It is quite telling that through all of this, I never even considered
> asking if vixen stood for anything!

Also, topical for the season:
https://www.youtube.com/watch?v=78c7vDFt6G8&feature=youtu.be&t=7

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

Correct.  You can get close but getting 100% of the way seems unlikely.

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

That's fine.  I think we should try to focus on merging some common
infrastructure because I don't think 75+ patch series are going to be
easy to get agreement on.

I'm not a huge fan of passing the domid via CPUID.  That's going to
be messy over time.  I do, however, like the idea of passing it as a
command line argument.  I'm happy to add support for that if that's
agreeable.

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

I think no matter what, we should try to get the first few patches merged
to add basic guest detection and hypercall support.

> * 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.x is what we're targetting.  That is indeed old but since since this
is a security issue, supporting a wide range of environments seems
like the right thing to do.

> * 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 never got a chance to try this out and see what breaks.

The one argument I'd make against it is that over time, I'd like to add
privileges to the domU in an attempt to improve performance.  We found
a lot of weird compatibility issues on older versions of Linux so I didn't
attempt to do any of this up front but in the long term, I would like to steal
some of the tricks from Xenner.

> I'm sure there are areas I've missed, but this is hopefully a start.

Thanks Andrew!

Regards,

Anthony Liguori

> ~Andrew
>
> _______________________________________________
> 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