[llvm-dev] Mitigating straight-line speculation vulnerability CVE-2020-13844

[Kristof Beyls via llvm-dev]

Hi,

A new speculative cache side-channel vulnerability has been published at
https://developer.arm.com/support/arm-security-updates/speculative-processor-vulnerability/downloads/straight-line-speculation,
named "straight-line speculation”, CVE-2020-13844.

In this email, I'd like to explain the toolchain mitigation we've prepared
to mitigate against this vulnerability for AArch64.  For the full details of the
vulnerability, please follow the above link.
The part of the vulnerability that is relevant to the toolchain mitigations
is as follows.
Some processors may speculatively execute the instructions immediately
following what should be a change in control flow, including RET (returns), BR
(indirect jumps) and BLR (indirect function calls). If the speculative
execution path contains a suitable code sequence, often described as a "Spectre
Revelation Gadget", such straight-line speculation could lead to changes in the
caches and similar structures that are indicative of secrets, making those
secrets vulnerable to revelation through timing analysis.

The gist of the mitigation is that for RET and BR instructions, a speculation
barrier is placed after them that prohibits incorrect speculation. Since these
barriers are never on the correct, architectural execution path, performance
overhead of this is expected to be low.

The gist of the mitigation for the BLR instruction is a bit more complicated,
to make sure that no barrier gets placed on the architectural execution path.
In summary, a
   BLR x<N>
instruction gets transformed to
   BL __llvm_slsblr_thunk_x<N>
instruction, with __llvm_slsblr_thunk_x<N> a thunk that contains
__llvm_slsblr_thunk_x<N>:
   BR x<N>
   speculation barrier

Therefore, the BLR instruction gets split into 2; one BL and one BR. This
transformation results in not inserting a speculation barrier on the
architectural execution path.

Please find patches for these mitigations on the below reviews:

1. https://reviews.llvm.org/D81399: [AArch64] Fix branch, terminator, etc properties for BRA* instructions.
2. https://reviews.llvm.org/D81400: [AArch64] Introduce AArch64SLSHardeningPass, which implements the hardening of RET and BR instructions.
3. https://reviews.llvm.org/D81401: [NFC] Refactor ThunkInserter to make it available for all targets.
4. https://reviews.llvm.org/D81402: [AArch64] Extend AArch64SLSHardeningPass to harden BLR instructions.
5. https://reviews.llvm.org/D81403: Work around GlobalISel limitation on Indirect Thunks.
6. https://reviews.llvm.org/D81404: [AArch64] Add clang command line support for -mharden-sls=
7. https://reviews.llvm.org/D81405: [AArch64] Avoid incompatibility between SLSBLR mitigation and BTI codegen, by only using X16 and X17 registers for BLRs.

There are a few known places where this toolchain mitigation leaves
instructions unmitigated:
* Some accesses to thread-local variables use a code sequence with a BLR
 instruction. This code sequence is part of the binary interface between
 compiler and linker. If this BLR instruction needs to be mitigated, it'd
 probably be best to do so in the linker. It seems that the code sequence
 for thread-local variable access is unlikely to lead to a Spectre Revalation
 Gadget.
* PLT stubs are produced by the linker and each contain a BLR instruction.
 It seems that at most only after the last PLT stub a spectre revalation
 gadget might appear.
* Use of BR, RET and BLR instructions in assembly are not mitigated.
* Use of BR, RET and BLR instructions in libraries and run-time library
 routines that are not recompiled with this toolchain mitigation are not
 mitigated.

We're also posting patches with similar functionality to gcc.

I'd like to request comments and feedback on the above patches.

Thanks,

Kristof

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200608/ef8b9958/attachment.html>