<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">
<div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">
<div>Hi,<br class="">
<font color="#5856d6" class=""><span style="caret-color: rgb(88, 86, 214);" class=""><br class="">
</span></font>A new speculative cache side-channel vulnerability has been published at</div>
<div><a href="https://developer.arm.com/support/arm-security-updates/speculative-processor-vulnerability/downloads/straight-line-speculation" class="">https://developer.arm.com/support/arm-security-updates/speculative-processor-vulnerability/downloads/straight-line-speculation</a>,</div>
<div>named "straight-line speculation”, CVE-2020-13844.<br class="">
<font color="#5856d6" class=""><span style="caret-color: rgb(88, 86, 214);" class=""><br class="">
</span></font>In this email, I'd like to explain the toolchain mitigation we've prepared<br class="">
to mitigate against this vulnerability for AArch64. For the full details of the<br class="">
vulnerability, please follow the above link.<br class="">
The part of the vulnerability that is relevant to the toolchain mitigations<br class="">
is as follows.<br class="">
Some processors may speculatively execute the instructions immediately<br class="">
following what should be a change in control flow, including RET (returns), BR<br class="">
(indirect jumps) and BLR (indirect function calls). If the speculative<br class="">
execution path contains a suitable code sequence, often described as a "Spectre<br class="">
Revelation Gadget", such straight-line speculation could lead to changes in the<br class="">
caches and similar structures that are indicative of secrets, making those<br class="">
secrets vulnerable to revelation through timing analysis.<br class="">
<font color="#5856d6" class=""><span style="caret-color: rgb(88, 86, 214);" class=""><br class="">
</span></font>The gist of the mitigation is that for RET and BR instructions, a speculation<br class="">
barrier is placed after them that prohibits incorrect speculation. Since these<br class="">
barriers are never on the correct, architectural execution path, performance<br class="">
overhead of this is expected to be low.<br class="">
<font color="#5856d6" class=""><span style="caret-color: rgb(88, 86, 214);" class=""><br class="">
</span></font>The gist of the mitigation for the BLR instruction is a bit more complicated,<br class="">
to make sure that no barrier gets placed on the architectural execution path.<br class="">
In summary, a<br class="">
BLR x<N><br class="">
instruction gets transformed to <br class="">
BL __llvm_slsblr_thunk_x<N><br class="">
instruction, with __llvm_slsblr_thunk_x<N> a thunk that contains<br class="">
__llvm_slsblr_thunk_x<N>:<br class="">
BR x<N><br class="">
speculation barrier<br class="">
<font color="#5856d6" class=""><span style="caret-color: rgb(88, 86, 214);" class=""><br class="">
</span></font>Therefore, the BLR instruction gets split into 2; one BL and one BR. This<br class="">
transformation results in not inserting a speculation barrier on the<br class="">
architectural execution path.<br class="">
<font color="#5856d6" class=""><span style="caret-color: rgb(88, 86, 214);" class=""><br class="">
</span></font>Please find patches for these mitigations on the below reviews:<br class="">
<br class="">
1. <a href="https://reviews.llvm.org/D81399" class="">https://reviews.llvm.org/D81399</a>: [AArch64] Fix branch, terminator, etc properties for BRA* instructions.<br class="">
2. <a href="https://reviews.llvm.org/D81400" class="">https://reviews.llvm.org/D81400</a>: [AArch64] Introduce AArch64SLSHardeningPass, which implements the hardening of RET and BR instructions.<br class="">
3. <a href="https://reviews.llvm.org/D81401" class="">https://reviews.llvm.org/D81401</a>: [NFC] Refactor ThunkInserter to make it available for all targets.<br class="">
4. <a href="https://reviews.llvm.org/D81402" class="">https://reviews.llvm.org/D81402</a>: [AArch64] Extend AArch64SLSHardeningPass to harden BLR instructions.<br class="">
5. <a href="https://reviews.llvm.org/D81403" class="">https://reviews.llvm.org/D81403</a>: Work around GlobalISel limitation on Indirect Thunks.<br class="">
6. <a href="https://reviews.llvm.org/D81404" class="">https://reviews.llvm.org/D81404</a>: [AArch64] Add clang command line support for -mharden-sls=<br class="">
7. <a href="https://reviews.llvm.org/D81405" class="">https://reviews.llvm.org/D81405</a>: [AArch64] Avoid incompatibility between SLSBLR mitigation and BTI codegen, by only using X16 and X17 registers for BLRs.<br class="">
<font color="#5856d6" class=""><span style="caret-color: rgb(88, 86, 214);" class=""><br class="">
</span></font>There are a few known places where this toolchain mitigation leaves<br class="">
instructions unmitigated:<br class="">
* Some accesses to thread-local variables use a code sequence with a BLR<br class="">
instruction. This code sequence is part of the binary interface between<br class="">
compiler and linker. If this BLR instruction needs to be mitigated, it'd<br class="">
probably be best to do so in the linker. It seems that the code sequence<br class="">
for thread-local variable access is unlikely to lead to a Spectre Revalation<br class="">
Gadget.<br class="">
* PLT stubs are produced by the linker and each contain a BLR instruction.<br class="">
It seems that at most only after the last PLT stub a spectre revalation<br class="">
gadget might appear.<br class="">
* Use of BR, RET and BLR instructions in assembly are not mitigated.<br class="">
* Use of BR, RET and BLR instructions in libraries and run-time library<br class="">
routines that are not recompiled with this toolchain mitigation are not<br class="">
mitigated.<br class="">
<font color="#5856d6" class=""><span style="caret-color: rgb(88, 86, 214);" class=""><br class="">
</span></font>We're also posting patches with similar functionality to gcc.<br class="">
<font color="#5856d6" class=""><span style="caret-color: rgb(88, 86, 214);" class=""><br class="">
</span></font>I'd like to request comments and feedback on the above patches.<br class="">
<font color="#5856d6" class=""><span style="caret-color: rgb(88, 86, 214);" class=""><br class="">
</span></font>Thanks,<br class="">
<font color="#5856d6" class=""><span style="caret-color: rgb(88, 86, 214);" class=""><br class="">
</span></font>Kristof<br class="">
</div>
<div><br class="">
</div>
</div>
</body>
</html>