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

[Michał Górny via llvm-dev]

On Mon, 2020-06-08 at 15:20 +0000, Kristof Beyls via llvm-dev wrote:
> 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 for doing this.  Are the patches suitable for backporting to
10.0.1?  I was trying to query on Bugzilla but it seems to be broken
at the moment.

-- 
Best regards,
Michał Górny

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 618 bytes
Desc: This is a digitally signed message part
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200620/97c96b61/attachment.sig>