Bug #11859
closedneed swapgs mitigation
100%
Updated by John Levon over 3 years ago
CVE-2019-1125 concerns speculation with "swapgs":
https://businessresources.bitdefender.com/bypassing-kpti-speculative-behavior-swapgs-instruction
The first variant is a version of "rogue system register read": userspace can speculatively execute swapgs, and use cache timing attacks of the speculatively-loaded kgsbase to figure out the value of kgsbase. This has no mitigation except future Intel CPUs. However, its impact for us is minimal, as it's mainly useful for defeating KASLR, and we don't have any KASLR.
The other two cases are about executing swapgs in the kernel. Anywhere that has:
if (some condition)
swapgs
is potentially vulnerable. Remember, userspace can control one of the gsbase values. If we are coming in from userspace, then we need to swapgs. If we speculate otherwise, we skip the swapgs, and speculatively execute (spexecute?) code such as:
movq %gs:offset, ...
Since the gs override is now using the user's gsbase, it can use this to leak kernel memory contents. (If it could find a suitable gadget to do so.)
The other case is when we're coming in from the kernel and we want to skip the gsbase, as we're already on the kernel's gsbase. If userspace can trick the kernel to avoid the swap, we can spexecute similar code as above
In both cases we need something that will serialize (and hence prevent any spexecution) after the swapgs's.
We're slightly paranoid in what we did, but basically any branch-dependent swapgs gets mitigation here. I also ripped out __swapgs() altogether as any usage needs to consider this problem so I'd like to keep it open-coded.
Intel eventually published a little more detail themselves:
Updated by John Levon over 3 years ago
It is difficult if not impossible to directly test if this mitigates the issue, since it's not known if there are exploitable gadgets in the vicinity of the relevant code. Instead, testing has focused on regression testing: various things like running os-tests, dtrace, kmdb, etc.
Updated by Electric Monk over 3 years ago
- Status changed from New to Closed
- % Done changed from 0 to 100
git commit 42cd19316c818c8b8283fc48263a1b4ce99cf049
commit 42cd19316c818c8b8283fc48263a1b4ce99cf049 Author: John Levon <john.levon@joyent.com> Date: 2019-11-08T14:07:12.000Z 11859 need swapgs mitigation Reviewed by: Dan McDonald <danmcd@joyent.com> Reviewed by: Jerry Jelinek <jerry.jelinek@joyent.com> Reviewed by: Robert Mustacchi <rm@fingolfin.org> Approved by: Gordon Ross <gordon.w.ross@gmail.com>