Hi, A new speculative cache side-channel vulnerability has been published at the link below, named "straight-line speculation" (SLS in this patch series). https://developer.arm.com/support/arm-security-updates/speculative-processor-vulnerability/downloads/straight-line-speculation This vulnerability has been given CVE number CVE-2020-13844.
We have prepared some toolchain mitigations for this vulnerability. These
mitigate against the RET, BR case and the BLR case mentioned in the linked
whitepaper.
The part of vulnerability relevant to these toolchain mitigations is as
follows:
Some processors may speculatively execute the instructions immediately
following what should be a change in control flow. The examples we mitigate in
this patch series are the instructions RET (return), BR (indirect jump) and BLR
(indirect function call).
Where the speculative path contains a suitable code sequence, often described
by researchers 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 posted here is:
Every RET and BR instruction has a speculation barrier placed directly after
it. These speculation barriers are not to be architecturally executed, so the
performance cost is expected to be low.
Each BLR instruction is replaced by a BL to a function stub consisting of a BR
instruction followed by a speculation barrier.
This alternate approach is used since the instructions directly after a BLR are
usually architecturally executed, and this approach ensures the speculation
barrier is off that architecturally executed path.
Arm has been unable to demonstrate straight line speculation past a BL or B
instruction, and so we believe the BL instruction can be used without a
barrier.
In summary, a
RET
will be transformed to
RET
<speculation barrier>
While a
BLR x<N>
will be transformed to a
BL __call_indirect_x<N>
call, with __call_indirect_x<N> being a thunk that looks like
__call_indirect_x<N>:
BR x<N>
<speculation barrier>
The patch series is structured as follows:
1) Introduce new command line arguments.
2) The RET/BR mitigation.
3) The BLR mitigation.
There are a few known places where this toolchain mitigation does not protect
against speculation places:
- Some accesses to thread-local variables use a code sequence including 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 this could introduce one spectre relevation gadget
after the last PLT stub.
- Use of BR, RET, or BLR instructions in assembly are not mitigated.
- Use of BR, RET, or BLR instructions in libraries and run-time library
routines that are not recompiled with this toolchain mitigation are not
mitigated.
N.b. patches with similar functionality are being posted to LLVM.
Thanks,
Matthew.
Entire patch series attached to cover letter.
all-patches.tar.gz
Description: application/gzip
