[MODERATED] Re: GPZv4

[Jon Masters <jcm@redhat.com>]

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

On 04/17/2018 10:48 PM, speck for Konrad Rzeszutek Wilk wrote:
> 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.
> 
> ?

I get the vibe that no prctl is going to be agreed here. We as a distro
can't introduce that without upstream support, so I'm currently thinking
it's a big hammer with "auto","on",off" options that defaults to
disabling MDD on boot with "auto" (which is the same logic as your
previous patch series, different terms). This is what I'm in the middle
of refactoring your previous patch series to do (and will send to you).

The performance hit is going to vary across uarches. It's up to 12% on
x86 systems if done globally, which is why I would like a prctl.

> 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'.

I'm refactoring your patches to recognize either "mdd" or "ssbd" (double
s, not sbb :) ) on x86 and then other arches can target the latter one.

> 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'.

Indeed. Here's the current text as I reworded it:

--- begin ---
mdd stands for "Memory Disambiguation Disable". It is used to disable
a common industry performance optimization known as "Speculative
Store Bypass" in which loads from addresses to which a recent store
has occurred may (speculatively) see an older value. Intel refers
to this feature as "Memory Disambiguation", which is part of their
"Smart Memory Access" capability in Haswell and later processors.

Some processors have an implementation bug that enables a cache
side-channel attack against such speculatively read values. An
attacker can create exploit code that allows them to read memory
outside of a sandbox environment (for example, malicious JavaScript
in a web page), or to perform more complex attacks against code
running within the same privilege level, e.g. via the stack.

We provide two sets of knobs. The first are x86 specific:

 nomdd
 mdd=[off,auto,on]

We also support cross-architecture versions of these:

 nossbd
 ssbd=[off,auto,on]

By default Memory Disambiguation is enabled hence the parameters are:

 - auto - if possible will disable Memory Disambiguation (MD) at boot
          if CPU is vulnerable to speculation attacks against MD
 - on   - disable Memory Disambiguation
 - off  - enable Memory Disambiguation

And as mentioned - some CPUs may have an Memory Disambiguation
implementation is not vulnerable to speculation attack. For those,
the 'auto' (default) option will pick the right choice.
--- end ---

> 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.

As it stands, I'm just refactoring to do the global knob. Regardless of
the prctl piece I think Thomas is 100% correct that we should have the
set get that right first, and then layer on any switching logic.

> 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?

This would be great. I'll send you what I have directly when done and
you can use or not according to what is decided as the direction.

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

The AMD bits were shared on the condition that MD not be disabled by
default on AMD without further discussion. Since I can't control what
others will do with those bits, I am not in a position to share them at
this time without further discussion with AMD. So, I think "no".

Jon.

-- 
Computer Architect | Sent from my Fedora powered laptop