

Spectre Mitigations Part 2
source link: https://www.tuicool.com/articles/hit/2EJNbif
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.

Inthe last post we covered Wasmjit’s mitigations for Spectre Variant 1, also known as Branch Check Bypass, or BCB. In this post we’ll cover Wasmjit’s mitigations for Spectre Variant 2, also known as Branch Target Injection, or BTI.
Description of the Vulnerability
Like BCB, the primary danger of BTI is unintended information leakage in the CPU’s cache after speculative execution through an incorrect branch prediction. Specifically, BTI is a vulnerability in how the branch predictor handles indirect branches on certain CPUs. An indirect branch is a branch whose destination is dynamically loaded from memory, for example:
(*obj->funcptr)();
With detailed knowledge of the internals of a CPU’s branch predictor, an attacker is able to exploit weaknesses in the branch predictor to control the destination of an indirect branch during speculative execution. Once the attacker is able to branch to arbitrary locations during mis-speculation, they can use the observed effects on the cache to infer the value of data that would otherwise be inaccessible.
There are multiple ways for an attacker to manipulate the CPU’s indirect branch predictor. One particularly insidious way allows an attacker to influence the indirect branch predictor from another thread. As in the last post, I’ll direct you to Google Project Zero’s post for more details.
Retpoline Mitigation for BTI
Different CPUs may use different methods for predicting indirect branches and, in turn, may require different BTI mitigations. For x86_64 CPUs, the de facto mitigation technique was invented by engineers at Google and is called “ retpoline ”. The retpoline technique is also recommended by Intel.
In many modern x86_64 CPUs, the method for predicting the destination
of the
ret
instruction
is different than the method used to predict the destination of the
jmp
or
call
instructions,
which are vulnerable to BTI. Taking that into account, retpoline works
by using the ret
instruction to perform indirect branches instead of
the usual jmp
or call
instructions. To show how that works, first
consider an indirect jmp
:
jmp *%rax
Now consider the equivalent retpoline sequence:
call go loop: pause lfence jmp loop go: mov %rax, (%rsp) ret
Upon execution of the call
instruction, the CPU pushes the return
address, i.e. the address of loop:
, to the top of stack at (%rsp)
and branches to go:
. At go:
, retpoline overwrites the top of the
stack with the desired destination address in %rax
. ret
then pops
the address from the top of the stack and branches there. If the CPU
doesn’t know the value of the destination address upon execution of ret
, then, due to the way ret
speculation works, it will
speculatively execute starting at loop:
and loop endlessly until the
destination address is resolved.
The corresponding retpoline sequence for call *%rax
works on a
similar principle.
Wasmjit Mitigations
Every indirect jump in Wasmjit is vulnerable to BTI. Fortunately, BTI can be automatically mitigated by the compiler. All major compilers provide automatic mitigation.
Since Wasmjit is a JIT, however, it must also make sure to not emit
vulnerable indirect branches at runtime. There are 2 WebAssembly instructions
that require an indirect branch:
br_table
and
call_indirect
.
Additionally Wasmjit emits indirect jumps in a few other places for
convenience of implementation. It was enough to change the instruction
sequences emitted in the affected areas.
Final Words
The burden incurred on general software developers by BTI is relatively low compared to BCB. It really only affects projects written in assembly code, or projects that emit assembly code, like like compilers and JITs. The impact on Wasmjit is minimal but persistent. BTI will need to be considered each time a new JIT backend is added. For now, Wasmjit only supports x86_64, but may need to address BTI again when AArch64 support is added.
Recommend
-
62
Mitigations landing for new class of timing attack Luke Wagner January 3, 2018 ...
-
80
SpecuCheck SpecuCheck is a Windows utility for checking the state of the software and hardware mitigations against CVE-2017-5754 (Meltdown), CVE-2017-5715 (Spectre v2), CVE-2018-3260 (Foreshadow), and CVE-2018-3639 (Spectre v4). It uses t...
-
34
Posted by Ivan Lozano, Information Security Engineer Android's switch to LLVM/Clang as the default platform compiler in Android 7.0 opened up more possibilities for improving our defense-in-depth security postu...
-
37
Spectre is a CPU vulnerability which allows an attacker in certain scenarios to read “secret” data on the victim’s machine. The vulnerability was first published by
-
59
Android’s switch to LLVM/Clang as the default platform compiler in Android 7.0 opened up more possibilities for improving our defense-in-depth security posture. In the past couple of releases, we've rolled out additional compiler-based mitigatio...
-
53
Amongst the initial reactions to Wasmjit were concerns about its vulnerability to Meltdown and Spectre . This isn’t surprising since Spectre primarily affects operating system...
-
14
Exploitation Mitigations The goal is to list exploitation mitigations added over time in various operating systems, software, libraries or hardware. It becomes handy to know if a given vulnerability is easily exploitable or not depen...
-
4
Testing shows AMD Zen 4 handling Spectre, Retbleed mitigations like a real champ...
-
9
Disabling Spectre V2 Mitigations Is What Can Impair AMD Ryzen 7000 Series Performance Written by Michael Larabel in
-
10
Closed Bug 1837602...
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK