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

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

On Fri, 5 Jan 2018, Juergen Gross wrote:
> 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.

Regardless of what we do as a stop-gap now (vixen for example), I think
we need to continue pursuing this solution because it is the only one
that can mitigate SP3 when VT-x is not available.

I have several users exactly in this condition, and this is the only
hope for them.

I think this series should be a blocker for 4.11.

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