Project

General

Profile

Actions

Bug #11859

closed

need swapgs mitigation

Added by John Levon over 2 years ago. Updated over 2 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
-
Start date:
Due date:
% Done:

100%

Estimated time:
Difficulty:
Medium
Tags:
Gerrit CR:
Actions #1

Updated by John Levon over 2 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:

https://software.intel.com/security-software-guidance/insights/deep-dive-intel-analysis-speculative-behavior-swapgs-and-segment-registers

Actions #2

Updated by John Levon over 2 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.

Actions #3

Updated by Electric Monk over 2 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>

Actions

Also available in: Atom PDF