Re: Ongoing/future speculative mitigation work

From: "Mihai Donțu" <mdontu@bitdefender.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>,
	Dario Faggioli <dfaggioli@suse.com>,
	Xen-devel List <xen-devel@lists.xen.org>
Cc: Juergen Gross <JGross@suse.com>,
	Lars Kurth <lars.kurth@citrix.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Wei Liu <wei.liu2@citrix.com>,
	Anthony Liguori <aliguori@amazon.com>,
	Sergey Dyasli <sergey.dyasli@citrix.com>,
	George Dunlap <george.dunlap@eu.citrix.com>,
	Ross Philipson <ross.philipson@oracle.com>,
	Daniel Kiper <daniel.kiper@oracle.com>,
	Konrad Wilk <konrad.wilk@oracle.com>,
	Marek Marczykowski <marmarek@invisiblethingslab.com>,
	Martin Pohlack <mpohlack@amazon.de>,
	Julien Grall <julien.grall@arm.com>,
	"Dannowski, Uwe" <uwed@amazon.de>,
	Jan Beulich <JBeulich@suse.com>,
	Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	Matt Wilson <msw@amazon.com>,
	Joao Martins <joao.m.martins@oracle.com>,
	"Woodhouse, David" <dwmw@amazon.co.uk>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: Ongoing/future speculative mitigation work
Date: Mon, 22 Oct 2018 12:32:54 +0300	[thread overview]
Message-ID: <1540200774.2833.8.camel@bitdefender.com> (raw)
In-Reply-To: <0fa1c7a6-d3bc-5ea3-ae65-f6f24b303134@citrix.com>

On Fri, 2018-10-19 at 13:17 +0100, Andrew Cooper wrote:
> [...]
> 
> > Therefore, although I certainly think we _must_ have the proper
> > scheduler enhancements in place (and in fact I'm working on that :-D)
> > it should IMO still be possible for the user to decide whether or not
> > to use them (either by opting-in or opting-out, I don't care much at
> > this stage).
> 
> I'm not suggesting that we leave people without a choice, but given an
> option which doesn't share siblings between different guests, it should
> be the default.

+1

> [...]
> 
> Its best to consider the secret-free Xen and scheduler improvements as
> orthogonal.  In particular, the secret-free Xen is defence in depth
> against SP1, and the risk of future issues, but does have
> non-speculative benefits as well.
> 
> That said, the only way to use HT and definitely be safe to L1TF without
> a secret-free Xen is to have the synchronised entry/exit logic working.
> 
> > > A solution to this issue was proposed, whereby Xen synchronises
> > > siblings on vmexit/entry, so we are never executing code in two different
> > > privilege levels.  Getting this working would make it safe to
> > > continue using hyperthreading even in the presence of L1TF.  
> > 
> > Err... ok, but we still want core-aware scheduling, or at least we want
> > to avoid having vcpus from different domains on siblings, don't we? In
> > order to avoid leaks between guests, I mean.
> 
> Ideally, we'd want all of these.  I expect the only reasonable way to
> develop them is one on top of another.

If there was a vote, I'd place the scheduler changes at the top.

-- 
Mihai Donțu

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