diff options
| author | Kristof Beyls <kristof.beyls@arm.com> | 2020-06-11 09:23:15 +0100 |
|---|---|---|
| committer | Kristof Beyls <kristof.beyls@arm.com> | 2020-06-12 07:34:33 +0100 |
| commit | c35ed40f4f1bd8afd709c5342b36f33c7c5b0fbd (patch) | |
| tree | 4d17d00a702435ea511a953f0b489be486beb2f2 /llvm/lib/Object/TapiFile.cpp | |
| parent | 6f0ce46873b609851634b2c77fc76bf8d580c3c6 (diff) | |
| download | llvm-c35ed40f4f1bd8afd709c5342b36f33c7c5b0fbd.zip llvm-c35ed40f4f1bd8afd709c5342b36f33c7c5b0fbd.tar.gz llvm-c35ed40f4f1bd8afd709c5342b36f33c7c5b0fbd.tar.bz2 | |
[AArch64] Extend AArch64SLSHardeningPass to harden BLR instructions.
To make sure that no barrier gets placed on the architectural execution
path, each
BLR x<N>
instruction gets transformed to a
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.
The mitigation is off by default and can be enabled by the
harden-sls-blr subtarget feature.
As a linker is allowed to clobber X16 and X17 on function calls, the
above code transformation would not be correct in case a linker does so
when N=16 or N=17. Therefore, when the mitigation is enabled, generation
of BLR x16 or BLR x17 is avoided.
As BLRA* indirect calls are not produced by LLVM currently, this does
not aim to implement support for those.
Differential Revision: https://reviews.llvm.org/D81402
Diffstat (limited to 'llvm/lib/Object/TapiFile.cpp')
0 files changed, 0 insertions, 0 deletions