Re: [Xen-devel] [PATCH FAIRLY-RFC 00/44] x86: Prerequisite work for a Xen KAISER solution

[Juergen Gross <jgross@xxxxxxxx>]

On 04/01/18 21:21, Andrew Cooper wrote:
> This work was developed as an SP3 mitigation, but shelved when it became clear
> that it wasn't viable to get done in the timeframe.
> 
> To protect against SP3 attacks, most mappings needs to be flushed while in
> user context.  However, to protect against all cross-VM attacks, it is
> necessary to ensure that the Xen stacks are not mapped in any other cpus
> address space, or an attacker can still recover at least the GPR state of
> separate VMs.

Above statement is too strict: it would be sufficient if no stacks of
other domains are mapped.

I'm just working on a proof of concept using dedicated per-vcpu stacks
for 64 bit pv domains. Those stacks would be mapped in the per-domain
region of the address space. I hope to have a RFC version of the patches
ready next week.

This would allow to remove the per physical cpu mappings in the guest
visible address space when doing page table isolation.

In order to avoid SP3 attacks to other vcpu's stacks of the same guest
we could extend the pv ABI to mark a guest's user L4 page table as
"single use", i.e. not allowed to be active on multiple vcpus at the
same time (introducing that ABI modification in the Linux kernel would
be simple, as the Linux kernel currently lacks support for cross-cpu
stack exploits and when that support is being added by per-cpu L4 user
page tables we could just chime in). A L4 page table marked as "single
use" would map the local vcpu stacks only.

> To have isolated stacks, Xen needs a per-pcpu isolated region, which requires
> that two pCPUs never share the same %cr3.  This is trivial for 32bit PV guests
> and HVM guests due to the existing per-vcpu Monitor Tables, but is problematic
> for 64bit PV guests, which will run on the same %cr3 when scheduling different
> threads from the same process.
> 
> To avoid breaking the PV ABI, Xen needs to shadow the guest L4 pagetables if
> it wants to maintain the unique %cr3 property it needs.
> 
> tl;dr The shadowing algorithm in pt-shadow.c is too much of a performance
> overhead to be viable, and very high risk to productise in an embargo window.
> If we want to continue down this route, we either need someone to have a
> clever alternative to the shadowing algorithm I came up with, or change the PV
> ABI to require VMs not to share L4 pagetables.
> 
> Either way, these patches are presented to start a discussion of the issues.
> The series as a whole is not in a suitable state for committing.

I think patch 1 should be excluded from that statement, as it is not
directly related to the series.


Juergen

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