[MODERATED] Re: GPZv4

[Jon Masters <jcm@redhat.com>]

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

On 04/17/2018 04:37 PM, speck for Borislav Petkov wrote:
> On Tue, Apr 17, 2018 at 03:56:55PM -0400, speck for Jon Masters wrote:
>> Let's make sure we're talking about the right thing when we talk about
>> things being on or off. I usually always talk about a performance
>> feature being on or off, not a mitigation. Therefore, I read the above
>> as "MD is off by default", meaning the performance feature is disabled.
> 
> I mean the opposite. MD is enabled, as it is the default setting
> normally, on any CPU that has MD. So the performance feature remains
> enabled.
> 
>> This is our current thinking. However, AMD disagree with this and prefer
>> to leave the feature enabled by default.
> 
> Yes.

Great! Then we're at least talking about the right thing, even if we
have differing opinions on the default ;)

[my one comment in this email on RHEL, feel free to skip next para]
Red Hat's perspective is that we need to be "secure by default". I would
/love/ to be able to leave MD enabled globally on all arches, but in
order for that to happen, everyone across the industry would have to
agree to that with no vendors going a different way at the 11th hour and
using it for PR win. To that end, I've asked all of the big players to
consider a commitment to this plan prior to RH making the default be
enabled. Intel and AMD agreed to go do some driving there, and I met
with MS in Redmond last week to discuss this in a bit more detail. If we
don't get such a plan in place, AMD would currently be the only uarch
for which we would leave the default of SSB enabled in RHEL (by virtue
of the terms under which we have the chicken bit information provided).

>> That would mean having to (at a minimum) address all of the userspace
>> exposure with prctl(), seccomp(), or other interfaces, and get that
>> all done within the next month. For the actual browsers, sure, there
>> will be process isolation updates.
> 
> Yes.

This is a fair amount of work. In particular, we don't have any prctl
defined yet and we need one for applications to use to toggle userspace.

> Paranoid people can boot with mdd=on - meaning "memory
> disambiguation disable - on"

Indeed.

>    [ and yap, if anything, we very very quickly need to agree on one
>      terminology and stick with it because the confusion will be insane...
>    ]
> 
> or, in your suggested nomenclature, ssb=off.
> 
> The finer-grained stuff we can do in parallel.

So we need to close on the following urgently:

1). What are we going to refer to this as?
	- MDD
	- SSB
	- something else?

In the case of "MDD" it's x86 specific and "enabling" it means you
disable a feature (MD). To me, that seems to be inverted logic. You
would set it to "on", "off", or "kernel" (MD only in userspace).

In the case of "SSB" it's more industry wide terminology but it's not
the Intel term. You would set it to "on", "off", or "userspace".

2). We need a prctl option for a task to request behavior for SSB. One
option could be a new PR_SET_MITIGATION where we then have minor
parameters for additional mitigations that are required later.

Can we get some closure on the two above asap?

Jon.

-- 
Computer Architect | Sent from my Fedora powered laptop