[MODERATED] GPZv4

* [MODERATED] GPZv4
@ 2018-04-17 18:26 Jon Masters
  2018-04-17 19:31 ` [MODERATED] GPZv4 Borislav Petkov
  0 siblings, 1 reply; 27+ messages in thread
From: Jon Masters @ 2018-04-17 18:26 UTC (permalink / raw)
  To: speck

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

Hi all,

We're working on numerous current and upcoming issues, alongside our
peer vendors. Looking forward to collaboration with everyone here (I
have some reproducers that I've built). I gather you're all read in on
those too, but meanwhile, let's discuss a few things about variant 4.

A broad range of vendors are impacted by variant 4 (Speculative Store
Bypass), but the exposure varies of course, as do the mitigations. I
have personally spoken with 10 different vendors so far and would like
to synthesize what I know below, along with some suggestions. I'll be
getting back to Konrad with some proposals for his patches rsn.

Classes of attack
-----------------

We're concerned not only with the (quite viable) attack against JITs and
sandboxes (e.g. JavaScript) in which a malicious address is written to a
variable whose type is subsequently changed and used as a memory gadget,
but also with stack attacks. Depending upon the uarch[0] it might be
(theoretically) possible to construct a gadget that reads memory based
upon reuse of older stack frames (older entry containing possibly
untrusted user data is forwarded speculatively). Similar works with
uninitialized variables in Java, though we haven't repro'd that yet.

The point is it's not just about turning of SSB/MD for specific
processes. It's potentially a bigger attack. At least AFAICS on x86
today the existing retpoline lfences keep us safe on syscall entry save
of registers at least up until we make the actual function call. But
after that, it's possible that a gadget could be found in a syscall.
This would mean either convincing ourselves that the stack attack is
infeasible, toggling the MD bit on every kernel entry (too painful in
most cases), or creating a scanning tool and looking for gadgets.

It is my believe anyway that we need at least following:

1). A boot time big hammer to disable SSB
	- I propose "ssb=" with options of "on", "off", and perhaps
	  later also "userspace" to allow it to be prctl()'d per task
	- It is unclear whether a "kernel" version makes sense
2). A new prctl that allows a task to request it be disabled (seccomp
alone isn't sufficient since we can't migrate everything to seccomp)

We would generally fallback to the first option for total safety but
hopefully convert most of the obvious attack vectors to use the second.
That is, if we can convince ourselves that the stack attack is unlikely
(and this will vary from one uarch to another).

RED HAT NOTE: On the RH end we are leaning toward default disabling SSB
globally on boot unless we can get all of the other vendors to agree
with leaving it on and have them make the ask/statement that this is
considered safe to do. The risk doesn't outweigh the benefit. AMD in
particular would like to retain this on by default, and I've instigated
discussions between them and Intel on this, as well as Microsoft.

Cross-architecture solution
---------------------------

Intel refer to this technique as "Smart Memory Access" and "Memory
Disambiguation", but the industry term (as used by GPZ) is "Speculative
Store Bypass". Therefore, I suggest that Linux refer to this technique
also as "SSB" for cross-architecture mitigation.

Here's the exposure as I understand it so far:

* Intel - They have exposed the new MD bit of SPEC_CTRL. The uarch will
default to MD enabled while Intel will provide recommendations. Plenty
of Intel folks already involved so I imagine they can handle this part.

* AMD - They have chicken bits that can disable SSB. They won't provide
these except on the condition that we agree not to disable by default.
Therefore, I have the magic bit info but can't share it quite yet. It
involves writing into two uarch specific MSRs and won't be SPEC_CTRL. I
can assist coordinating whatever is agreed here getting back to AMD.

* Arm - I've requested a new SMC for SSB disabling (SMCC similar to for
Spectre) and this has been allocated. It's currently under review. This
would fit with "ssb=" nomenclature and behave identically to x86. I've
spoken with a half dozen different Arm licensees about individual
exposure and their ability to adopt the overall SMC interface on kernel
entry/exit as necessary, or via a global hammer at boot time. I hear
Will has the ball on the Arm kernel end for working this and I would
like us to agree soon on kernel interfaces. I can assist coordinating.

* IBM p - A new "stf-flush" (store forward flush) instruction has been
allocated that will be used on every entry/exit to/from the kernel to
mitigate against the kernel stack attack. Working on additional bits. I
would like them to align around something like "ssb" for options. I am
coordinating with the architecture team, while Anton has the ball on the
IBM kernel end for this. I can summarize any interfaces agreed here.

* IBM z - Not vulnerable to the stack attack. Working on defining
additional facility that will allow for further mitigations. I am
coordinating with the design team, expect Martin will handle kernel. I
can coordinate whatever is agreed here feeding back into IBM z team.

The above is just for architectures that we track on the Red Hat end.

Next steps
----------

Currently looking at Konrad's initial patches. I'm proposing to change
"mdd" to "ssb" as above, and only define the big hammer for now while we
discuss what should be the prctl() type interfaces for per-task control.

Best,

Jon.

[0] Some uarches will allow speculative store bypass for same base
pointer, while others will not. For example, Intel will allow a bypass
to occur for the same stack location, but AMD never will provided a
common stack base pointer is used. Similarly, IBM z never will.

-- 
Computer Architect | Sent from my Fedora powered laptop

^ permalink raw reply	[flat|nested] 27+ messages in thread