[MODERATED] Re: GPZv4

[Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>]

On Tue, Apr 17, 2018 at 06:02:47PM -0400, speck for Jon Masters wrote:
> On 04/17/2018 06:01 PM, speck for Thomas Gleixner wrote:
> > On Tue, 17 Apr 2018, speck for Jiri Kosina wrote:
> > 
> >> On Tue, 17 Apr 2018, speck for Jon Masters wrote:
> >>
> >>> The proposal would be that it only allows you to go one-way. You can say
> >>> "I am vulnerable", turn off MD, but you can't say "I am not vulnerable".
> >>
> >> That means we probably never reach full coverage; the problem with this 
> >> "opt-in" aproach is that noone would ever bother (even more so as time 
> >> passess) to add this explicit "I am vulnerable" call into the source; it's 
> >> basically out of control, and thus unmaintainable.
> > 
> > We had the same discussion with the per process kpti control ...
> 
> Ok. Big hammer it is.

1) Are you thinking of a mix of a) big hammer (at boot up always disable
memory disambiguation, aka mdd=auto or sbb=auto or sbbd=auto), along with b)
inverting the prctl to opt-out - that is applications that feel they are safe
can opt-out and do an prctl saying: memory disambiguation security issues
be dammed - I want memory disambiguation on to get that 5% performance
back. Obviously they would need to be new to know about this bit.

And then any old application would suffer the performance penalty but
would be secure.

?

2). SBB vs MDD vs SBBD.

MDD = Memory Disambiguation Disable
SBB = Speculative Store Bypass
SBBD = Speculative Store Bypass Disable

Thomas likes 'MDD', Jon likes 'SBB', but he is also fine with 'SBBD'.

3). Semantics of SBBD or MDD boot time knob. I followed the way spectre_v2 did it.

That is this is knob is to disable something and they are:
'auto' - follow what the platform recommends. This being linux upstream
         discussion means following:
		on AMD - enable memory disambiguation.
		on Intel - no clue. For testing purposes I've left it
                           as disable memory disambiguation.

'off' - ignore what the vendor/distro recommends.
'force' - disable it, even if the platform says enable it (like on AMD).

And then two more to figure out when to apply the security glue:
'boot' or 'userspace'.

This ties in to 1) - that is if we are not going to provide a 'userspace'
option then there is no need to even provide the 'boot' option
so then this sub-discussion becomes moot.

Thomas (and Linus if you are skulking in the background) - you are the
top-dog(s) here, can you give the guidance please so I can redo the
patches on Thursday/Friday?

P.S.
I know the AMD secret sauce bits and can do the patches for this, but
are other folks authorized for this?