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