[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

  • To: Juergen Gross <jgross@xxxxxxxx>
  • From: Stefano Stabellini <sstabellini@xxxxxxxxxx>
  • Date: Tue, 9 Jan 2018 15:14:13 -0800 (PST)
  • Authentication-results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=kernel.org
  • Authentication-results: mail.kernel.org; spf=none smtp.mailfrom=sstabellini@xxxxxxxxxx
  • Cc: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Xen-devel <xen-devel@xxxxxxxxxxxxx>
  • Delivery-date: Tue, 09 Jan 2018 23:14:41 +0000
  • Dmarc-filter: OpenDMARC Filter v1.3.2 mail.kernel.org 933C72064D
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

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



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.