Re: [patch RFC 5/5] x86/speculation: Add basic speculation control code

[David Woodhouse <dwmw2@infradead.org>]

[-- Attachment #1: Type: text/plain, Size: 1784 bytes --]

On Wed, 2018-01-10 at 13:07 +0100, Andrea Arcangeli wrote:
> On Wed, Jan 10, 2018 at 01:01:58PM +0100, Andrea Arcangeli wrote:
> > On Wed, Jan 10, 2018 at 11:58:54AM +0000, David Woodhouse wrote:
> > > On Wed, 2018-01-10 at 12:54 +0100, Andrea Arcangeli wrote:
> > > > On Wed, Jan 10, 2018 at 09:27:59AM +0000, David Woodhouse wrote:
> > > > > I don't know why you're calling that 'IBRS=2'; are you getting
> > > > confused
> > > > > by Andrea's distro horridness?
> > > > 
> > > > Eh, yes he's got confused. ibrs_enabled 2 simply means to leave IBRS
> > > > set in SPEC_CTLR 100% of the time, except in guest mode.
> > > 
> > > On all current hardware, if you only set IBRS when you exit a guest,
> > > then you are not protecting yourself from userspace at all. IBRS acts
> > > as a *barrier* in all current hardware.
> > 
> > Kernel memory is 100% protected if you set only IBRS at vmexit.
> > 
> > Once IBRS is set, there's no way any userland (nor host nor guest) can
> > attack the kernel memory through spectre variant#2.
> > 
> > What is not protected is host userland from guest userland which is
> > point 3 in the email I posted earlier and I already provided all
> > details there on how to fix that purely theoretical issue not part of
> > the PoC with the provided debugfs tunables, so I won't repeat here.
> 
> Also I read in another email you thought IBRS is a barrier or
> something, it's not, it's purely temporarily preventing the CPU to
> speculate through IBP BTB whatever,

No.

IBRS is like a barrier. You must write it between the 'problematic'
loading of the branch targets, and the kernel code which might be
affected.

You cannot, on current hardware, merely set it once and forget about
it. That is not sufficient.

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5213 bytes --]