maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/llvm/test/CodeGen/ARM/speculation-hardening-sls.ll

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

263 lines
12 KiB
LLVM
Raw Normal View History

[ARM] Reset speculation-hardening-sls.ll test checks. The commit e497b12a69604b6d691312a30f6b86da4f18f7f8 went and regenerated all the checks lines in the Arm speculation-hardening-sls.ll test in a way that removed most of the important checks. This just resets them back to how they were before, with the single character fix to change: ; NOHARDENARM: {{bxge lr$}} to ; NOHARDENARM: {{bxgt lr$}} Differential Revision: https://reviews.llvm.org/D111074
2021-10-05 17:51:18 +08:00
; RUN: llc -mattr=harden-sls-retbr -mattr=harden-sls-blr -verify-machineinstrs -mtriple=armv8-linux-gnueabi < %s | FileCheck %s --check-prefixes=CHECK,ARM,HARDEN,HARDEN-COMDAT,ISBDSB -dump-input-context=100
; RUN: llc -mattr=harden-sls-retbr -mattr=harden-sls-blr -verify-machineinstrs -mtriple=thumbv8-linux-gnueabi < %s | FileCheck %s --check-prefixes=CHECK,THUMB,HARDENTHUMB,HARDEN,HARDEN-COMDAT,ISBDSB -dump-input-context=100
; RUN: llc -mattr=harden-sls-retbr -mattr=harden-sls-blr -mattr=+sb -verify-machineinstrs -mtriple=armv8-linux-gnueabi < %s | FileCheck %s --check-prefixes=CHECK,ARM,HARDEN,HARDEN-COMDAT,SB -dump-input-context=100
; RUN: llc -mattr=harden-sls-retbr -mattr=harden-sls-blr -mattr=+sb -verify-machineinstrs -mtriple=thumbv8-linux-gnueabi < %s | FileCheck %s --check-prefixes=CHECK,THUMB,HARDENTHUMB,HARDEN,HARDEN-COMDAT,SB -dump-input-context=100
; RUN: llc -mattr=harden-sls-retbr -mattr=harden-sls-blr -mattr=harden-sls-nocomdat -verify-machineinstrs -mtriple=armv8-linux-gnueabi < %s | FileCheck %s --check-prefixes=CHECK,ARM,HARDEN,HARDEN-COMDAT-OFF,ISBDSB -dump-input-context=100
; RUN: llc -mattr=harden-sls-retbr -mattr=harden-sls-blr -mattr=harden-sls-nocomdat -verify-machineinstrs -mtriple=thumbv8-linux-gnueabi < %s | FileCheck %s --check-prefixes=CHECK,THUMB,HARDENTHUMB,HARDEN,HARDEN-COMDAT-OFF,ISBDSB -dump-input-context=100
; RUN: llc -mattr=harden-sls-retbr -mattr=harden-sls-blr -mattr=harden-sls-nocomdat -mattr=+sb -verify-machineinstrs -mtriple=armv8-linux-gnueabi < %s | FileCheck %s --check-prefixes=CHECK,ARM,HARDEN,HARDEN-COMDAT-OFF,SB -dump-input-context=100
; RUN: llc -mattr=harden-sls-retbr -mattr=harden-sls-blr -mattr=harden-sls-nocomdat -mattr=+sb -verify-machineinstrs -mtriple=thumbv8-linux-gnueabi < %s | FileCheck %s --check-prefixes=CHECK,THUMB,HARDENTHUMB,HARDEN,HARDEN-COMDAT-OFF,SB -dump-input-context=100
; RUN: llc -verify-machineinstrs -mtriple=armv8-linux-gnueabi < %s | FileCheck %s --check-prefixes=CHECK,ARM,NOHARDENARM -dump-input-context=100
; RUN: llc -verify-machineinstrs -mtriple=thumbv8-linux-gnueabi < %s | FileCheck %s --check-prefixes=CHECK,THUMB,NOHARDENTHUMB
; RUN: llc -global-isel -global-isel-abort=0 -mattr=harden-sls-retbr -mattr=harden-sls-blr -verify-machineinstrs -mtriple=armv8-linux-gnueabi < %s | FileCheck %s --check-prefixes=CHECK,ARM,HARDEN,HARDEN-COMDAT,ISBDSB
; RUN: llc -global-isel -global-isel-abort=0 -mattr=harden-sls-retbr -mattr=harden-sls-blr -verify-machineinstrs -mtriple=thumbv8-linux-gnueabi < %s | FileCheck %s --check-prefixes=CHECK,THUMB,HARDENTHUMB,HARDEN,HARDEN-COMDAT,ISBDSB
; RUN: llc -global-isel -global-isel-abort=0 -mattr=harden-sls-retbr -mattr=harden-sls-nocomdat -mattr=harden-sls-blr -verify-machineinstrs -mtriple=armv8-linux-gnueabi < %s | FileCheck %s --check-prefixes=CHECK,ARM,HARDEN,HARDEN-COMDAT-OFF,ISBDSB
; RUN: llc -global-isel -global-isel-abort=0 -mattr=harden-sls-retbr -mattr=harden-sls-nocomdat -mattr=harden-sls-blr -verify-machineinstrs -mtriple=thumbv8-linux-gnueabi < %s | FileCheck %s --check-prefixes=CHECK,THUMB,HARDENTHUMB,HARDEN,HARDEN-COMDAT-OFF,ISBDSB
; RUN: llc -global-isel -global-isel-abort=0 -mattr=harden-sls-retbr -mattr=harden-sls-blr -mattr=+sb -verify-machineinstrs -mtriple=armv8-linux-gnueabi < %s | FileCheck %s --check-prefixes=CHECK,ARM,HARDEN,SB
; RUN: llc -global-isel -global-isel-abort=0 -mattr=harden-sls-retbr -mattr=harden-sls-blr -mattr=+sb -verify-machineinstrs -mtriple=thumbv8-linux-gnueabi < %s | FileCheck %s --check-prefixes=CHECK,THUMB,HARDENTHUMB,HARDEN,SB
; RUN: llc -fast-isel -mattr=harden-sls-retbr -mattr=harden-sls-blr -verify-machineinstrs -mtriple=armv8-linux-gnueabi < %s | FileCheck %s --check-prefixes=CHECK,ARM,HARDEN,HARDEN-COMDAT,ISBDSB
; RUN: llc -fast-isel -mattr=harden-sls-retbr -mattr=harden-sls-blr -verify-machineinstrs -mtriple=thumbv8-linux-gnueabi < %s | FileCheck %s --check-prefixes=CHECK,THUMB,HARDENTHUMB,HARDEN,HARDEN-COMDAT,ISBDSB
; RUN: llc -fast-isel -mattr=harden-sls-retbr -mattr=harden-sls-blr -mattr=harden-sls-nocomdat -verify-machineinstrs -mtriple=armv8-linux-gnueabi < %s | FileCheck %s --check-prefixes=CHECK,ARM,HARDEN,HARDEN-COMDAT-OFF,ISBDSB
; RUN: llc -fast-isel -mattr=harden-sls-retbr -mattr=harden-sls-blr -mattr=harden-sls-nocomdat -verify-machineinstrs -mtriple=thumbv8-linux-gnueabi < %s | FileCheck %s --check-prefixes=CHECK,THUMB,HARDENTHUMB,HARDEN,HARDEN-COMDAT-OFF,ISBDSB
; RUN: llc -fast-isel -mattr=harden-sls-retbr -mattr=harden-sls-blr -mattr=+sb -verify-machineinstrs -mtriple=armv8-linux-gnueabi < %s | FileCheck %s --check-prefixes=CHECK,ARM,HARDEN,SB
; RUN: llc -fast-isel -mattr=harden-sls-retbr -mattr=harden-sls-blr -mattr=+sb -verify-machineinstrs -mtriple=thumbv8-linux-gnueabi < %s | FileCheck %s --check-prefixes=CHECK,THUMB,HARDENTHUMB,HARDEN,SB
[ARM] Implement harden-sls-retbr for ARM mode Some processors may speculatively execute the instructions immediately following indirect control flow, such as returns, indirect jumps and indirect function calls. To avoid a potential miss-speculatively executed gadget after these instructions leaking secrets through side channels, this pass places a speculation barrier immediately after every indirect control flow where control flow doesn't return to the next instruction, such as returns and indirect jumps, but not indirect function calls. Hardening of indirect function calls will be done in a later, independent patch. This patch is implementing the same functionality as the AArch64 counter part implemented in https://reviews.llvm.org/D81400. For AArch64, returns and indirect jumps only occur on RET and BR instructions and hence the function attribute to control the hardening is called "harden-sls-retbr" there. On AArch32, there is a much wider variety of instructions that can trigger an indirect unconditional control flow change. I've decided to stick with the name "harden-sls-retbr" as introduced for the corresponding AArch64 mitigation. This patch implements this for ARM mode. A future patch will extend this to also support Thumb mode. The inserted barriers are never on the correct, architectural execution path, and therefore performance overhead of this is expected to be low. To ensure these barriers are never on an architecturally executed path, when the harden-sls-retbr function attribute is present, indirect control flow is never conditionalized/predicated. On targets that implement that Armv8.0-SB Speculation Barrier extension, a single SB instruction is emitted that acts as a speculation barrier. On other targets, a DSB SYS followed by a ISB is emitted to act as a speculation barrier. These speculation barriers are implemented as pseudo instructions to avoid later passes to analyze them and potentially remove them. The mitigation is off by default and can be enabled by the harden-sls-retbr subtarget feature. Differential Revision: https://reviews.llvm.org/D92395
2020-10-29 05:04:11 +08:00
; Function Attrs: norecurse nounwind readnone
define dso_local i32 @double_return(i32 %a, i32 %b) local_unnamed_addr {
entry:
%cmp = icmp sgt i32 %a, 0
br i1 %cmp, label %if.then, label %if.else
if.then: ; preds = %entry
; Make a very easy, very likely to predicate return (BX LR), to test that
; it will not get predicated when sls-hardening is enabled.
%mul = mul i32 %b, %a
ret i32 %mul
[ARM] Reset speculation-hardening-sls.ll test checks. The commit e497b12a69604b6d691312a30f6b86da4f18f7f8 went and regenerated all the checks lines in the Arm speculation-hardening-sls.ll test in a way that removed most of the important checks. This just resets them back to how they were before, with the single character fix to change: ; NOHARDENARM: {{bxge lr$}} to ; NOHARDENARM: {{bxgt lr$}} Differential Revision: https://reviews.llvm.org/D111074
2021-10-05 17:51:18 +08:00
; CHECK-LABEL: double_return:
; HARDEN: {{bx lr$}}
; NOHARDENARM: {{bxgt lr$}}
; NOHARDENTHUMB: {{bx lr$}}
; ISBDSB-NEXT: dsb sy
; ISBDSB-NEXT: isb
; SB-NEXT: {{ sb$}}
[ARM] Implement harden-sls-retbr for ARM mode Some processors may speculatively execute the instructions immediately following indirect control flow, such as returns, indirect jumps and indirect function calls. To avoid a potential miss-speculatively executed gadget after these instructions leaking secrets through side channels, this pass places a speculation barrier immediately after every indirect control flow where control flow doesn't return to the next instruction, such as returns and indirect jumps, but not indirect function calls. Hardening of indirect function calls will be done in a later, independent patch. This patch is implementing the same functionality as the AArch64 counter part implemented in https://reviews.llvm.org/D81400. For AArch64, returns and indirect jumps only occur on RET and BR instructions and hence the function attribute to control the hardening is called "harden-sls-retbr" there. On AArch32, there is a much wider variety of instructions that can trigger an indirect unconditional control flow change. I've decided to stick with the name "harden-sls-retbr" as introduced for the corresponding AArch64 mitigation. This patch implements this for ARM mode. A future patch will extend this to also support Thumb mode. The inserted barriers are never on the correct, architectural execution path, and therefore performance overhead of this is expected to be low. To ensure these barriers are never on an architecturally executed path, when the harden-sls-retbr function attribute is present, indirect control flow is never conditionalized/predicated. On targets that implement that Armv8.0-SB Speculation Barrier extension, a single SB instruction is emitted that acts as a speculation barrier. On other targets, a DSB SYS followed by a ISB is emitted to act as a speculation barrier. These speculation barriers are implemented as pseudo instructions to avoid later passes to analyze them and potentially remove them. The mitigation is off by default and can be enabled by the harden-sls-retbr subtarget feature. Differential Revision: https://reviews.llvm.org/D92395
2020-10-29 05:04:11 +08:00
if.else: ; preds = %entry
%div3 = sdiv i32 %a, %b
%div2 = sdiv i32 %a, %div3
%div1 = sdiv i32 %a, %div2
ret i32 %div1
[ARM] Reset speculation-hardening-sls.ll test checks. The commit e497b12a69604b6d691312a30f6b86da4f18f7f8 went and regenerated all the checks lines in the Arm speculation-hardening-sls.ll test in a way that removed most of the important checks. This just resets them back to how they were before, with the single character fix to change: ; NOHARDENARM: {{bxge lr$}} to ; NOHARDENARM: {{bxgt lr$}} Differential Revision: https://reviews.llvm.org/D111074
2021-10-05 17:51:18 +08:00
; CHECK: {{bx lr$}}
; ISBDSB-NEXT: dsb sy
; ISBDSB-NEXT: isb
; SB-NEXT: {{ sb$}}
; CHECK-NEXT: .Lfunc_end
[ARM] Implement harden-sls-retbr for ARM mode Some processors may speculatively execute the instructions immediately following indirect control flow, such as returns, indirect jumps and indirect function calls. To avoid a potential miss-speculatively executed gadget after these instructions leaking secrets through side channels, this pass places a speculation barrier immediately after every indirect control flow where control flow doesn't return to the next instruction, such as returns and indirect jumps, but not indirect function calls. Hardening of indirect function calls will be done in a later, independent patch. This patch is implementing the same functionality as the AArch64 counter part implemented in https://reviews.llvm.org/D81400. For AArch64, returns and indirect jumps only occur on RET and BR instructions and hence the function attribute to control the hardening is called "harden-sls-retbr" there. On AArch32, there is a much wider variety of instructions that can trigger an indirect unconditional control flow change. I've decided to stick with the name "harden-sls-retbr" as introduced for the corresponding AArch64 mitigation. This patch implements this for ARM mode. A future patch will extend this to also support Thumb mode. The inserted barriers are never on the correct, architectural execution path, and therefore performance overhead of this is expected to be low. To ensure these barriers are never on an architecturally executed path, when the harden-sls-retbr function attribute is present, indirect control flow is never conditionalized/predicated. On targets that implement that Armv8.0-SB Speculation Barrier extension, a single SB instruction is emitted that acts as a speculation barrier. On other targets, a DSB SYS followed by a ISB is emitted to act as a speculation barrier. These speculation barriers are implemented as pseudo instructions to avoid later passes to analyze them and potentially remove them. The mitigation is off by default and can be enabled by the harden-sls-retbr subtarget feature. Differential Revision: https://reviews.llvm.org/D92395
2020-10-29 05:04:11 +08:00
}
@__const.indirect_branch.ptr = private unnamed_addr constant [2 x i8*] [i8* blockaddress(@indirect_branch, %return), i8* blockaddress(@indirect_branch, %l2)], align 8
; Function Attrs: norecurse nounwind readnone
define dso_local i32 @indirect_branch(i32 %a, i32 %b, i32 %i) {
[ARM] Reset speculation-hardening-sls.ll test checks. The commit e497b12a69604b6d691312a30f6b86da4f18f7f8 went and regenerated all the checks lines in the Arm speculation-hardening-sls.ll test in a way that removed most of the important checks. This just resets them back to how they were before, with the single character fix to change: ; NOHARDENARM: {{bxge lr$}} to ; NOHARDENARM: {{bxgt lr$}} Differential Revision: https://reviews.llvm.org/D111074
2021-10-05 17:51:18 +08:00
; CHECK-LABEL: indirect_branch:
[ARM] Implement harden-sls-retbr for ARM mode Some processors may speculatively execute the instructions immediately following indirect control flow, such as returns, indirect jumps and indirect function calls. To avoid a potential miss-speculatively executed gadget after these instructions leaking secrets through side channels, this pass places a speculation barrier immediately after every indirect control flow where control flow doesn't return to the next instruction, such as returns and indirect jumps, but not indirect function calls. Hardening of indirect function calls will be done in a later, independent patch. This patch is implementing the same functionality as the AArch64 counter part implemented in https://reviews.llvm.org/D81400. For AArch64, returns and indirect jumps only occur on RET and BR instructions and hence the function attribute to control the hardening is called "harden-sls-retbr" there. On AArch32, there is a much wider variety of instructions that can trigger an indirect unconditional control flow change. I've decided to stick with the name "harden-sls-retbr" as introduced for the corresponding AArch64 mitigation. This patch implements this for ARM mode. A future patch will extend this to also support Thumb mode. The inserted barriers are never on the correct, architectural execution path, and therefore performance overhead of this is expected to be low. To ensure these barriers are never on an architecturally executed path, when the harden-sls-retbr function attribute is present, indirect control flow is never conditionalized/predicated. On targets that implement that Armv8.0-SB Speculation Barrier extension, a single SB instruction is emitted that acts as a speculation barrier. On other targets, a DSB SYS followed by a ISB is emitted to act as a speculation barrier. These speculation barriers are implemented as pseudo instructions to avoid later passes to analyze them and potentially remove them. The mitigation is off by default and can be enabled by the harden-sls-retbr subtarget feature. Differential Revision: https://reviews.llvm.org/D92395
2020-10-29 05:04:11 +08:00
entry:
%idxprom = sext i32 %i to i64
%arrayidx = getelementptr inbounds [2 x i8*], [2 x i8*]* @__const.indirect_branch.ptr, i64 0, i64 %idxprom
%0 = load i8*, i8** %arrayidx, align 8
indirectbr i8* %0, [label %return, label %l2]
[ARM] Reset speculation-hardening-sls.ll test checks. The commit e497b12a69604b6d691312a30f6b86da4f18f7f8 went and regenerated all the checks lines in the Arm speculation-hardening-sls.ll test in a way that removed most of the important checks. This just resets them back to how they were before, with the single character fix to change: ; NOHARDENARM: {{bxge lr$}} to ; NOHARDENARM: {{bxgt lr$}} Differential Revision: https://reviews.llvm.org/D111074
2021-10-05 17:51:18 +08:00
; ARM: bx r0
; THUMB: mov pc, r0
; ISBDSB-NEXT: dsb sy
; ISBDSB-NEXT: isb
; SB-NEXT: {{ sb$}}
[ARM] Implement harden-sls-retbr for ARM mode Some processors may speculatively execute the instructions immediately following indirect control flow, such as returns, indirect jumps and indirect function calls. To avoid a potential miss-speculatively executed gadget after these instructions leaking secrets through side channels, this pass places a speculation barrier immediately after every indirect control flow where control flow doesn't return to the next instruction, such as returns and indirect jumps, but not indirect function calls. Hardening of indirect function calls will be done in a later, independent patch. This patch is implementing the same functionality as the AArch64 counter part implemented in https://reviews.llvm.org/D81400. For AArch64, returns and indirect jumps only occur on RET and BR instructions and hence the function attribute to control the hardening is called "harden-sls-retbr" there. On AArch32, there is a much wider variety of instructions that can trigger an indirect unconditional control flow change. I've decided to stick with the name "harden-sls-retbr" as introduced for the corresponding AArch64 mitigation. This patch implements this for ARM mode. A future patch will extend this to also support Thumb mode. The inserted barriers are never on the correct, architectural execution path, and therefore performance overhead of this is expected to be low. To ensure these barriers are never on an architecturally executed path, when the harden-sls-retbr function attribute is present, indirect control flow is never conditionalized/predicated. On targets that implement that Armv8.0-SB Speculation Barrier extension, a single SB instruction is emitted that acts as a speculation barrier. On other targets, a DSB SYS followed by a ISB is emitted to act as a speculation barrier. These speculation barriers are implemented as pseudo instructions to avoid later passes to analyze them and potentially remove them. The mitigation is off by default and can be enabled by the harden-sls-retbr subtarget feature. Differential Revision: https://reviews.llvm.org/D92395
2020-10-29 05:04:11 +08:00
l2: ; preds = %entry
br label %return
[ARM] Reset speculation-hardening-sls.ll test checks. The commit e497b12a69604b6d691312a30f6b86da4f18f7f8 went and regenerated all the checks lines in the Arm speculation-hardening-sls.ll test in a way that removed most of the important checks. This just resets them back to how they were before, with the single character fix to change: ; NOHARDENARM: {{bxge lr$}} to ; NOHARDENARM: {{bxgt lr$}} Differential Revision: https://reviews.llvm.org/D111074
2021-10-05 17:51:18 +08:00
; CHECK: {{bx lr$}}
; ISBDSB-NEXT: dsb sy
; ISBDSB-NEXT: isb
; SB-NEXT: {{ sb$}}
[ARM] Implement harden-sls-retbr for ARM mode Some processors may speculatively execute the instructions immediately following indirect control flow, such as returns, indirect jumps and indirect function calls. To avoid a potential miss-speculatively executed gadget after these instructions leaking secrets through side channels, this pass places a speculation barrier immediately after every indirect control flow where control flow doesn't return to the next instruction, such as returns and indirect jumps, but not indirect function calls. Hardening of indirect function calls will be done in a later, independent patch. This patch is implementing the same functionality as the AArch64 counter part implemented in https://reviews.llvm.org/D81400. For AArch64, returns and indirect jumps only occur on RET and BR instructions and hence the function attribute to control the hardening is called "harden-sls-retbr" there. On AArch32, there is a much wider variety of instructions that can trigger an indirect unconditional control flow change. I've decided to stick with the name "harden-sls-retbr" as introduced for the corresponding AArch64 mitigation. This patch implements this for ARM mode. A future patch will extend this to also support Thumb mode. The inserted barriers are never on the correct, architectural execution path, and therefore performance overhead of this is expected to be low. To ensure these barriers are never on an architecturally executed path, when the harden-sls-retbr function attribute is present, indirect control flow is never conditionalized/predicated. On targets that implement that Armv8.0-SB Speculation Barrier extension, a single SB instruction is emitted that acts as a speculation barrier. On other targets, a DSB SYS followed by a ISB is emitted to act as a speculation barrier. These speculation barriers are implemented as pseudo instructions to avoid later passes to analyze them and potentially remove them. The mitigation is off by default and can be enabled by the harden-sls-retbr subtarget feature. Differential Revision: https://reviews.llvm.org/D92395
2020-10-29 05:04:11 +08:00
return: ; preds = %entry, %l2
%retval.0 = phi i32 [ 1, %l2 ], [ 0, %entry ]
ret i32 %retval.0
[ARM] Reset speculation-hardening-sls.ll test checks. The commit e497b12a69604b6d691312a30f6b86da4f18f7f8 went and regenerated all the checks lines in the Arm speculation-hardening-sls.ll test in a way that removed most of the important checks. This just resets them back to how they were before, with the single character fix to change: ; NOHARDENARM: {{bxge lr$}} to ; NOHARDENARM: {{bxgt lr$}} Differential Revision: https://reviews.llvm.org/D111074
2021-10-05 17:51:18 +08:00
; CHECK: {{bx lr$}}
; ISBDSB-NEXT: dsb sy
; ISBDSB-NEXT: isb
; SB-NEXT: {{ sb$}}
; CHECK-NEXT: .Lfunc_end
[ARM] Implement harden-sls-retbr for ARM mode Some processors may speculatively execute the instructions immediately following indirect control flow, such as returns, indirect jumps and indirect function calls. To avoid a potential miss-speculatively executed gadget after these instructions leaking secrets through side channels, this pass places a speculation barrier immediately after every indirect control flow where control flow doesn't return to the next instruction, such as returns and indirect jumps, but not indirect function calls. Hardening of indirect function calls will be done in a later, independent patch. This patch is implementing the same functionality as the AArch64 counter part implemented in https://reviews.llvm.org/D81400. For AArch64, returns and indirect jumps only occur on RET and BR instructions and hence the function attribute to control the hardening is called "harden-sls-retbr" there. On AArch32, there is a much wider variety of instructions that can trigger an indirect unconditional control flow change. I've decided to stick with the name "harden-sls-retbr" as introduced for the corresponding AArch64 mitigation. This patch implements this for ARM mode. A future patch will extend this to also support Thumb mode. The inserted barriers are never on the correct, architectural execution path, and therefore performance overhead of this is expected to be low. To ensure these barriers are never on an architecturally executed path, when the harden-sls-retbr function attribute is present, indirect control flow is never conditionalized/predicated. On targets that implement that Armv8.0-SB Speculation Barrier extension, a single SB instruction is emitted that acts as a speculation barrier. On other targets, a DSB SYS followed by a ISB is emitted to act as a speculation barrier. These speculation barriers are implemented as pseudo instructions to avoid later passes to analyze them and potentially remove them. The mitigation is off by default and can be enabled by the harden-sls-retbr subtarget feature. Differential Revision: https://reviews.llvm.org/D92395
2020-10-29 05:04:11 +08:00
}
define i32 @asmgoto() {
entry:
[ARM] Reset speculation-hardening-sls.ll test checks. The commit e497b12a69604b6d691312a30f6b86da4f18f7f8 went and regenerated all the checks lines in the Arm speculation-hardening-sls.ll test in a way that removed most of the important checks. This just resets them back to how they were before, with the single character fix to change: ; NOHARDENARM: {{bxge lr$}} to ; NOHARDENARM: {{bxgt lr$}} Differential Revision: https://reviews.llvm.org/D111074
2021-10-05 17:51:18 +08:00
; CHECK-LABEL: asmgoto:
[ARM] Implement harden-sls-retbr for ARM mode Some processors may speculatively execute the instructions immediately following indirect control flow, such as returns, indirect jumps and indirect function calls. To avoid a potential miss-speculatively executed gadget after these instructions leaking secrets through side channels, this pass places a speculation barrier immediately after every indirect control flow where control flow doesn't return to the next instruction, such as returns and indirect jumps, but not indirect function calls. Hardening of indirect function calls will be done in a later, independent patch. This patch is implementing the same functionality as the AArch64 counter part implemented in https://reviews.llvm.org/D81400. For AArch64, returns and indirect jumps only occur on RET and BR instructions and hence the function attribute to control the hardening is called "harden-sls-retbr" there. On AArch32, there is a much wider variety of instructions that can trigger an indirect unconditional control flow change. I've decided to stick with the name "harden-sls-retbr" as introduced for the corresponding AArch64 mitigation. This patch implements this for ARM mode. A future patch will extend this to also support Thumb mode. The inserted barriers are never on the correct, architectural execution path, and therefore performance overhead of this is expected to be low. To ensure these barriers are never on an architecturally executed path, when the harden-sls-retbr function attribute is present, indirect control flow is never conditionalized/predicated. On targets that implement that Armv8.0-SB Speculation Barrier extension, a single SB instruction is emitted that acts as a speculation barrier. On other targets, a DSB SYS followed by a ISB is emitted to act as a speculation barrier. These speculation barriers are implemented as pseudo instructions to avoid later passes to analyze them and potentially remove them. The mitigation is off by default and can be enabled by the harden-sls-retbr subtarget feature. Differential Revision: https://reviews.llvm.org/D92395
2020-10-29 05:04:11 +08:00
callbr void asm sideeffect "B $0", "X"(i8* blockaddress(@asmgoto, %d))
to label %asm.fallthrough [label %d]
; The asm goto above produces a direct branch:
[ARM] Reset speculation-hardening-sls.ll test checks. The commit e497b12a69604b6d691312a30f6b86da4f18f7f8 went and regenerated all the checks lines in the Arm speculation-hardening-sls.ll test in a way that removed most of the important checks. This just resets them back to how they were before, with the single character fix to change: ; NOHARDENARM: {{bxge lr$}} to ; NOHARDENARM: {{bxgt lr$}} Differential Revision: https://reviews.llvm.org/D111074
2021-10-05 17:51:18 +08:00
; CHECK: @APP
; CHECK-NEXT: {{^[ \t]+b }}
; CHECK-NEXT: @NO_APP
[ARM] Implement harden-sls-retbr for ARM mode Some processors may speculatively execute the instructions immediately following indirect control flow, such as returns, indirect jumps and indirect function calls. To avoid a potential miss-speculatively executed gadget after these instructions leaking secrets through side channels, this pass places a speculation barrier immediately after every indirect control flow where control flow doesn't return to the next instruction, such as returns and indirect jumps, but not indirect function calls. Hardening of indirect function calls will be done in a later, independent patch. This patch is implementing the same functionality as the AArch64 counter part implemented in https://reviews.llvm.org/D81400. For AArch64, returns and indirect jumps only occur on RET and BR instructions and hence the function attribute to control the hardening is called "harden-sls-retbr" there. On AArch32, there is a much wider variety of instructions that can trigger an indirect unconditional control flow change. I've decided to stick with the name "harden-sls-retbr" as introduced for the corresponding AArch64 mitigation. This patch implements this for ARM mode. A future patch will extend this to also support Thumb mode. The inserted barriers are never on the correct, architectural execution path, and therefore performance overhead of this is expected to be low. To ensure these barriers are never on an architecturally executed path, when the harden-sls-retbr function attribute is present, indirect control flow is never conditionalized/predicated. On targets that implement that Armv8.0-SB Speculation Barrier extension, a single SB instruction is emitted that acts as a speculation barrier. On other targets, a DSB SYS followed by a ISB is emitted to act as a speculation barrier. These speculation barriers are implemented as pseudo instructions to avoid later passes to analyze them and potentially remove them. The mitigation is off by default and can be enabled by the harden-sls-retbr subtarget feature. Differential Revision: https://reviews.llvm.org/D92395
2020-10-29 05:04:11 +08:00
; For direct branches, no mitigation is needed.
; ISDDSB-NOT: dsb sy
[ARM] Reset speculation-hardening-sls.ll test checks. The commit e497b12a69604b6d691312a30f6b86da4f18f7f8 went and regenerated all the checks lines in the Arm speculation-hardening-sls.ll test in a way that removed most of the important checks. This just resets them back to how they were before, with the single character fix to change: ; NOHARDENARM: {{bxge lr$}} to ; NOHARDENARM: {{bxgt lr$}} Differential Revision: https://reviews.llvm.org/D111074
2021-10-05 17:51:18 +08:00
; SB-NOT: {{ sb$}}
[ARM] Implement harden-sls-retbr for ARM mode Some processors may speculatively execute the instructions immediately following indirect control flow, such as returns, indirect jumps and indirect function calls. To avoid a potential miss-speculatively executed gadget after these instructions leaking secrets through side channels, this pass places a speculation barrier immediately after every indirect control flow where control flow doesn't return to the next instruction, such as returns and indirect jumps, but not indirect function calls. Hardening of indirect function calls will be done in a later, independent patch. This patch is implementing the same functionality as the AArch64 counter part implemented in https://reviews.llvm.org/D81400. For AArch64, returns and indirect jumps only occur on RET and BR instructions and hence the function attribute to control the hardening is called "harden-sls-retbr" there. On AArch32, there is a much wider variety of instructions that can trigger an indirect unconditional control flow change. I've decided to stick with the name "harden-sls-retbr" as introduced for the corresponding AArch64 mitigation. This patch implements this for ARM mode. A future patch will extend this to also support Thumb mode. The inserted barriers are never on the correct, architectural execution path, and therefore performance overhead of this is expected to be low. To ensure these barriers are never on an architecturally executed path, when the harden-sls-retbr function attribute is present, indirect control flow is never conditionalized/predicated. On targets that implement that Armv8.0-SB Speculation Barrier extension, a single SB instruction is emitted that acts as a speculation barrier. On other targets, a DSB SYS followed by a ISB is emitted to act as a speculation barrier. These speculation barriers are implemented as pseudo instructions to avoid later passes to analyze them and potentially remove them. The mitigation is off by default and can be enabled by the harden-sls-retbr subtarget feature. Differential Revision: https://reviews.llvm.org/D92395
2020-10-29 05:04:11 +08:00
asm.fallthrough: ; preds = %entry
ret i32 0
[ARM] Reset speculation-hardening-sls.ll test checks. The commit e497b12a69604b6d691312a30f6b86da4f18f7f8 went and regenerated all the checks lines in the Arm speculation-hardening-sls.ll test in a way that removed most of the important checks. This just resets them back to how they were before, with the single character fix to change: ; NOHARDENARM: {{bxge lr$}} to ; NOHARDENARM: {{bxgt lr$}} Differential Revision: https://reviews.llvm.org/D111074
2021-10-05 17:51:18 +08:00
; CHECK: {{bx lr$}}
; ISBDSB-NEXT: dsb sy
; ISBDSB-NEXT: isb
; SB-NEXT: {{ sb$}}
[ARM] Implement harden-sls-retbr for ARM mode Some processors may speculatively execute the instructions immediately following indirect control flow, such as returns, indirect jumps and indirect function calls. To avoid a potential miss-speculatively executed gadget after these instructions leaking secrets through side channels, this pass places a speculation barrier immediately after every indirect control flow where control flow doesn't return to the next instruction, such as returns and indirect jumps, but not indirect function calls. Hardening of indirect function calls will be done in a later, independent patch. This patch is implementing the same functionality as the AArch64 counter part implemented in https://reviews.llvm.org/D81400. For AArch64, returns and indirect jumps only occur on RET and BR instructions and hence the function attribute to control the hardening is called "harden-sls-retbr" there. On AArch32, there is a much wider variety of instructions that can trigger an indirect unconditional control flow change. I've decided to stick with the name "harden-sls-retbr" as introduced for the corresponding AArch64 mitigation. This patch implements this for ARM mode. A future patch will extend this to also support Thumb mode. The inserted barriers are never on the correct, architectural execution path, and therefore performance overhead of this is expected to be low. To ensure these barriers are never on an architecturally executed path, when the harden-sls-retbr function attribute is present, indirect control flow is never conditionalized/predicated. On targets that implement that Armv8.0-SB Speculation Barrier extension, a single SB instruction is emitted that acts as a speculation barrier. On other targets, a DSB SYS followed by a ISB is emitted to act as a speculation barrier. These speculation barriers are implemented as pseudo instructions to avoid later passes to analyze them and potentially remove them. The mitigation is off by default and can be enabled by the harden-sls-retbr subtarget feature. Differential Revision: https://reviews.llvm.org/D92395
2020-10-29 05:04:11 +08:00
d: ; preds = %asm.fallthrough, %entry
ret i32 1
[ARM] Reset speculation-hardening-sls.ll test checks. The commit e497b12a69604b6d691312a30f6b86da4f18f7f8 went and regenerated all the checks lines in the Arm speculation-hardening-sls.ll test in a way that removed most of the important checks. This just resets them back to how they were before, with the single character fix to change: ; NOHARDENARM: {{bxge lr$}} to ; NOHARDENARM: {{bxgt lr$}} Differential Revision: https://reviews.llvm.org/D111074
2021-10-05 17:51:18 +08:00
; CHECK: {{bx lr$}}
; ISBDSB-NEXT: dsb sy
; ISBDSB-NEXT: isb
; SB-NEXT: {{ sb$}}
; CHECK-NEXT: .Lfunc_end
[ARM] Implement harden-sls-retbr for ARM mode Some processors may speculatively execute the instructions immediately following indirect control flow, such as returns, indirect jumps and indirect function calls. To avoid a potential miss-speculatively executed gadget after these instructions leaking secrets through side channels, this pass places a speculation barrier immediately after every indirect control flow where control flow doesn't return to the next instruction, such as returns and indirect jumps, but not indirect function calls. Hardening of indirect function calls will be done in a later, independent patch. This patch is implementing the same functionality as the AArch64 counter part implemented in https://reviews.llvm.org/D81400. For AArch64, returns and indirect jumps only occur on RET and BR instructions and hence the function attribute to control the hardening is called "harden-sls-retbr" there. On AArch32, there is a much wider variety of instructions that can trigger an indirect unconditional control flow change. I've decided to stick with the name "harden-sls-retbr" as introduced for the corresponding AArch64 mitigation. This patch implements this for ARM mode. A future patch will extend this to also support Thumb mode. The inserted barriers are never on the correct, architectural execution path, and therefore performance overhead of this is expected to be low. To ensure these barriers are never on an architecturally executed path, when the harden-sls-retbr function attribute is present, indirect control flow is never conditionalized/predicated. On targets that implement that Armv8.0-SB Speculation Barrier extension, a single SB instruction is emitted that acts as a speculation barrier. On other targets, a DSB SYS followed by a ISB is emitted to act as a speculation barrier. These speculation barriers are implemented as pseudo instructions to avoid later passes to analyze them and potentially remove them. The mitigation is off by default and can be enabled by the harden-sls-retbr subtarget feature. Differential Revision: https://reviews.llvm.org/D92395
2020-10-29 05:04:11 +08:00
}
; Check that indirect branches produced through switch jump tables are also
; hardened:
define dso_local i32 @jumptable(i32 %a, i32 %b) {
[ARM] Reset speculation-hardening-sls.ll test checks. The commit e497b12a69604b6d691312a30f6b86da4f18f7f8 went and regenerated all the checks lines in the Arm speculation-hardening-sls.ll test in a way that removed most of the important checks. This just resets them back to how they were before, with the single character fix to change: ; NOHARDENARM: {{bxge lr$}} to ; NOHARDENARM: {{bxgt lr$}} Differential Revision: https://reviews.llvm.org/D111074
2021-10-05 17:51:18 +08:00
; CHECK-LABEL: jumptable:
[ARM] Implement harden-sls-retbr for ARM mode Some processors may speculatively execute the instructions immediately following indirect control flow, such as returns, indirect jumps and indirect function calls. To avoid a potential miss-speculatively executed gadget after these instructions leaking secrets through side channels, this pass places a speculation barrier immediately after every indirect control flow where control flow doesn't return to the next instruction, such as returns and indirect jumps, but not indirect function calls. Hardening of indirect function calls will be done in a later, independent patch. This patch is implementing the same functionality as the AArch64 counter part implemented in https://reviews.llvm.org/D81400. For AArch64, returns and indirect jumps only occur on RET and BR instructions and hence the function attribute to control the hardening is called "harden-sls-retbr" there. On AArch32, there is a much wider variety of instructions that can trigger an indirect unconditional control flow change. I've decided to stick with the name "harden-sls-retbr" as introduced for the corresponding AArch64 mitigation. This patch implements this for ARM mode. A future patch will extend this to also support Thumb mode. The inserted barriers are never on the correct, architectural execution path, and therefore performance overhead of this is expected to be low. To ensure these barriers are never on an architecturally executed path, when the harden-sls-retbr function attribute is present, indirect control flow is never conditionalized/predicated. On targets that implement that Armv8.0-SB Speculation Barrier extension, a single SB instruction is emitted that acts as a speculation barrier. On other targets, a DSB SYS followed by a ISB is emitted to act as a speculation barrier. These speculation barriers are implemented as pseudo instructions to avoid later passes to analyze them and potentially remove them. The mitigation is off by default and can be enabled by the harden-sls-retbr subtarget feature. Differential Revision: https://reviews.llvm.org/D92395
2020-10-29 05:04:11 +08:00
entry:
switch i32 %b, label %sw.epilog [
i32 0, label %sw.bb
i32 1, label %sw.bb1
i32 3, label %sw.bb3
i32 4, label %sw.bb5
]
[ARM] Reset speculation-hardening-sls.ll test checks. The commit e497b12a69604b6d691312a30f6b86da4f18f7f8 went and regenerated all the checks lines in the Arm speculation-hardening-sls.ll test in a way that removed most of the important checks. This just resets them back to how they were before, with the single character fix to change: ; NOHARDENARM: {{bxge lr$}} to ; NOHARDENARM: {{bxgt lr$}} Differential Revision: https://reviews.llvm.org/D111074
2021-10-05 17:51:18 +08:00
; ARM: ldr pc, [{{r[0-9]}}, {{r[0-9]}}, lsl #2]
; NOHARDENTHUMB: tbb [pc, {{r[0-9]}}]
; HARDENTHUMB: mov pc, {{r[0-9]}}
; ISBDSB-NEXT: dsb sy
; ISBDSB-NEXT: isb
; SB-NEXT: {{ sb$}}
[ARM] Implement harden-sls-retbr for ARM mode Some processors may speculatively execute the instructions immediately following indirect control flow, such as returns, indirect jumps and indirect function calls. To avoid a potential miss-speculatively executed gadget after these instructions leaking secrets through side channels, this pass places a speculation barrier immediately after every indirect control flow where control flow doesn't return to the next instruction, such as returns and indirect jumps, but not indirect function calls. Hardening of indirect function calls will be done in a later, independent patch. This patch is implementing the same functionality as the AArch64 counter part implemented in https://reviews.llvm.org/D81400. For AArch64, returns and indirect jumps only occur on RET and BR instructions and hence the function attribute to control the hardening is called "harden-sls-retbr" there. On AArch32, there is a much wider variety of instructions that can trigger an indirect unconditional control flow change. I've decided to stick with the name "harden-sls-retbr" as introduced for the corresponding AArch64 mitigation. This patch implements this for ARM mode. A future patch will extend this to also support Thumb mode. The inserted barriers are never on the correct, architectural execution path, and therefore performance overhead of this is expected to be low. To ensure these barriers are never on an architecturally executed path, when the harden-sls-retbr function attribute is present, indirect control flow is never conditionalized/predicated. On targets that implement that Armv8.0-SB Speculation Barrier extension, a single SB instruction is emitted that acts as a speculation barrier. On other targets, a DSB SYS followed by a ISB is emitted to act as a speculation barrier. These speculation barriers are implemented as pseudo instructions to avoid later passes to analyze them and potentially remove them. The mitigation is off by default and can be enabled by the harden-sls-retbr subtarget feature. Differential Revision: https://reviews.llvm.org/D92395
2020-10-29 05:04:11 +08:00
sw.bb: ; preds = %entry
%add = shl nsw i32 %a, 1
br label %sw.bb1
sw.bb1: ; preds = %entry, %sw.bb
%a.addr.0 = phi i32 [ %a, %entry ], [ %add, %sw.bb ]
%add2 = shl nsw i32 %a.addr.0, 1
br label %sw.bb3
sw.bb3: ; preds = %entry, %sw.bb1
%a.addr.1 = phi i32 [ %a, %entry ], [ %add2, %sw.bb1 ]
%add4 = shl nsw i32 %a.addr.1, 1
br label %sw.bb5
sw.bb5: ; preds = %entry, %sw.bb3
%a.addr.2 = phi i32 [ %a, %entry ], [ %add4, %sw.bb3 ]
%add6 = shl nsw i32 %a.addr.2, 1
br label %sw.epilog
sw.epilog: ; preds = %sw.bb5, %entry
%a.addr.3 = phi i32 [ %a, %entry ], [ %add6, %sw.bb5 ]
ret i32 %a.addr.3
[ARM] Reset speculation-hardening-sls.ll test checks. The commit e497b12a69604b6d691312a30f6b86da4f18f7f8 went and regenerated all the checks lines in the Arm speculation-hardening-sls.ll test in a way that removed most of the important checks. This just resets them back to how they were before, with the single character fix to change: ; NOHARDENARM: {{bxge lr$}} to ; NOHARDENARM: {{bxgt lr$}} Differential Revision: https://reviews.llvm.org/D111074
2021-10-05 17:51:18 +08:00
; CHECK: {{bx lr$}}
; ISBDSB-NEXT: dsb sy
; ISBDSB-NEXT: isb
; SB-NEXT: {{ sb$}}
[ARM] Implement harden-sls-retbr for ARM mode Some processors may speculatively execute the instructions immediately following indirect control flow, such as returns, indirect jumps and indirect function calls. To avoid a potential miss-speculatively executed gadget after these instructions leaking secrets through side channels, this pass places a speculation barrier immediately after every indirect control flow where control flow doesn't return to the next instruction, such as returns and indirect jumps, but not indirect function calls. Hardening of indirect function calls will be done in a later, independent patch. This patch is implementing the same functionality as the AArch64 counter part implemented in https://reviews.llvm.org/D81400. For AArch64, returns and indirect jumps only occur on RET and BR instructions and hence the function attribute to control the hardening is called "harden-sls-retbr" there. On AArch32, there is a much wider variety of instructions that can trigger an indirect unconditional control flow change. I've decided to stick with the name "harden-sls-retbr" as introduced for the corresponding AArch64 mitigation. This patch implements this for ARM mode. A future patch will extend this to also support Thumb mode. The inserted barriers are never on the correct, architectural execution path, and therefore performance overhead of this is expected to be low. To ensure these barriers are never on an architecturally executed path, when the harden-sls-retbr function attribute is present, indirect control flow is never conditionalized/predicated. On targets that implement that Armv8.0-SB Speculation Barrier extension, a single SB instruction is emitted that acts as a speculation barrier. On other targets, a DSB SYS followed by a ISB is emitted to act as a speculation barrier. These speculation barriers are implemented as pseudo instructions to avoid later passes to analyze them and potentially remove them. The mitigation is off by default and can be enabled by the harden-sls-retbr subtarget feature. Differential Revision: https://reviews.llvm.org/D92395
2020-10-29 05:04:11 +08:00
}
[ARM] Harden indirect calls against SLS To make sure that no barrier gets placed on the architectural execution path, each indirect call calling the function in register rN, it gets transformed to a direct call to __llvm_slsblr_thunk_mode_rN. mode is either arm or thumb, depending on the mode of where the indirect call happens. The llvm_slsblr_thunk_mode_rN thunk contains: bx rN <speculation barrier> Therefore, the indirect call gets split into 2; one direct call and one indirect jump. 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 r12 on function calls, the above code transformation is not correct in case a linker does so. Similarly, the transformation is not correct when register lr is used. Avoiding r12/lr being used is done in a follow-on patch to make reviewing this code easier. Differential Revision: https://reviews.llvm.org/D92468
2020-11-21 00:11:17 +08:00
define dso_local i32 @indirect_call(
i32 (...)* nocapture %f1, i32 (...)* nocapture %f2) {
entry:
[ARM] Reset speculation-hardening-sls.ll test checks. The commit e497b12a69604b6d691312a30f6b86da4f18f7f8 went and regenerated all the checks lines in the Arm speculation-hardening-sls.ll test in a way that removed most of the important checks. This just resets them back to how they were before, with the single character fix to change: ; NOHARDENARM: {{bxge lr$}} to ; NOHARDENARM: {{bxgt lr$}} Differential Revision: https://reviews.llvm.org/D111074
2021-10-05 17:51:18 +08:00
; CHECK-LABEL: indirect_call:
[ARM] Harden indirect calls against SLS To make sure that no barrier gets placed on the architectural execution path, each indirect call calling the function in register rN, it gets transformed to a direct call to __llvm_slsblr_thunk_mode_rN. mode is either arm or thumb, depending on the mode of where the indirect call happens. The llvm_slsblr_thunk_mode_rN thunk contains: bx rN <speculation barrier> Therefore, the indirect call gets split into 2; one direct call and one indirect jump. 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 r12 on function calls, the above code transformation is not correct in case a linker does so. Similarly, the transformation is not correct when register lr is used. Avoiding r12/lr being used is done in a follow-on patch to make reviewing this code easier. Differential Revision: https://reviews.llvm.org/D92468
2020-11-21 00:11:17 +08:00
%callee.knr.cast = bitcast i32 (...)* %f1 to i32 ()*
%call = tail call i32 %callee.knr.cast()
; HARDENARM: bl {{__llvm_slsblr_thunk_arm_r[0-9]+$}}
[ARM] Reset speculation-hardening-sls.ll test checks. The commit e497b12a69604b6d691312a30f6b86da4f18f7f8 went and regenerated all the checks lines in the Arm speculation-hardening-sls.ll test in a way that removed most of the important checks. This just resets them back to how they were before, with the single character fix to change: ; NOHARDENARM: {{bxge lr$}} to ; NOHARDENARM: {{bxgt lr$}} Differential Revision: https://reviews.llvm.org/D111074
2021-10-05 17:51:18 +08:00
; HARDENTHUMB: bl {{__llvm_slsblr_thunk_thumb_r[0-9]+$}}
[ARM] Harden indirect calls against SLS To make sure that no barrier gets placed on the architectural execution path, each indirect call calling the function in register rN, it gets transformed to a direct call to __llvm_slsblr_thunk_mode_rN. mode is either arm or thumb, depending on the mode of where the indirect call happens. The llvm_slsblr_thunk_mode_rN thunk contains: bx rN <speculation barrier> Therefore, the indirect call gets split into 2; one direct call and one indirect jump. 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 r12 on function calls, the above code transformation is not correct in case a linker does so. Similarly, the transformation is not correct when register lr is used. Avoiding r12/lr being used is done in a follow-on patch to make reviewing this code easier. Differential Revision: https://reviews.llvm.org/D92468
2020-11-21 00:11:17 +08:00
%callee.knr.cast1 = bitcast i32 (...)* %f2 to i32 ()*
%call2 = tail call i32 %callee.knr.cast1()
; HARDENARM: bl {{__llvm_slsblr_thunk_arm_r[0-9]+$}}
[ARM] Reset speculation-hardening-sls.ll test checks. The commit e497b12a69604b6d691312a30f6b86da4f18f7f8 went and regenerated all the checks lines in the Arm speculation-hardening-sls.ll test in a way that removed most of the important checks. This just resets them back to how they were before, with the single character fix to change: ; NOHARDENARM: {{bxge lr$}} to ; NOHARDENARM: {{bxgt lr$}} Differential Revision: https://reviews.llvm.org/D111074
2021-10-05 17:51:18 +08:00
; HARDENTHUMB: bl {{__llvm_slsblr_thunk_thumb_r[0-9]+$}}
[ARM] Harden indirect calls against SLS To make sure that no barrier gets placed on the architectural execution path, each indirect call calling the function in register rN, it gets transformed to a direct call to __llvm_slsblr_thunk_mode_rN. mode is either arm or thumb, depending on the mode of where the indirect call happens. The llvm_slsblr_thunk_mode_rN thunk contains: bx rN <speculation barrier> Therefore, the indirect call gets split into 2; one direct call and one indirect jump. 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 r12 on function calls, the above code transformation is not correct in case a linker does so. Similarly, the transformation is not correct when register lr is used. Avoiding r12/lr being used is done in a follow-on patch to make reviewing this code easier. Differential Revision: https://reviews.llvm.org/D92468
2020-11-21 00:11:17 +08:00
%add = add nsw i32 %call2, %call
ret i32 %add
[ARM] Reset speculation-hardening-sls.ll test checks. The commit e497b12a69604b6d691312a30f6b86da4f18f7f8 went and regenerated all the checks lines in the Arm speculation-hardening-sls.ll test in a way that removed most of the important checks. This just resets them back to how they were before, with the single character fix to change: ; NOHARDENARM: {{bxge lr$}} to ; NOHARDENARM: {{bxgt lr$}} Differential Revision: https://reviews.llvm.org/D111074
2021-10-05 17:51:18 +08:00
; CHECK: .Lfunc_end
[ARM] Harden indirect calls against SLS To make sure that no barrier gets placed on the architectural execution path, each indirect call calling the function in register rN, it gets transformed to a direct call to __llvm_slsblr_thunk_mode_rN. mode is either arm or thumb, depending on the mode of where the indirect call happens. The llvm_slsblr_thunk_mode_rN thunk contains: bx rN <speculation barrier> Therefore, the indirect call gets split into 2; one direct call and one indirect jump. 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 r12 on function calls, the above code transformation is not correct in case a linker does so. Similarly, the transformation is not correct when register lr is used. Avoiding r12/lr being used is done in a follow-on patch to make reviewing this code easier. Differential Revision: https://reviews.llvm.org/D92468
2020-11-21 00:11:17 +08:00
}
; verify calling through a function pointer.
@a = dso_local local_unnamed_addr global i32 (...)* null, align 8
@b = dso_local local_unnamed_addr global i32 0, align 4
define dso_local void @indirect_call_global() local_unnamed_addr {
[ARM] Reset speculation-hardening-sls.ll test checks. The commit e497b12a69604b6d691312a30f6b86da4f18f7f8 went and regenerated all the checks lines in the Arm speculation-hardening-sls.ll test in a way that removed most of the important checks. This just resets them back to how they were before, with the single character fix to change: ; NOHARDENARM: {{bxge lr$}} to ; NOHARDENARM: {{bxgt lr$}} Differential Revision: https://reviews.llvm.org/D111074
2021-10-05 17:51:18 +08:00
; CHECK-LABEL: indirect_call_global:
[ARM] Harden indirect calls against SLS To make sure that no barrier gets placed on the architectural execution path, each indirect call calling the function in register rN, it gets transformed to a direct call to __llvm_slsblr_thunk_mode_rN. mode is either arm or thumb, depending on the mode of where the indirect call happens. The llvm_slsblr_thunk_mode_rN thunk contains: bx rN <speculation barrier> Therefore, the indirect call gets split into 2; one direct call and one indirect jump. 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 r12 on function calls, the above code transformation is not correct in case a linker does so. Similarly, the transformation is not correct when register lr is used. Avoiding r12/lr being used is done in a follow-on patch to make reviewing this code easier. Differential Revision: https://reviews.llvm.org/D92468
2020-11-21 00:11:17 +08:00
entry:
%0 = load i32 ()*, i32 ()** bitcast (i32 (...)** @a to i32 ()**), align 8
%call = tail call i32 %0() nounwind
; HARDENARM: bl {{__llvm_slsblr_thunk_arm_r[0-9]+$}}
[ARM] Reset speculation-hardening-sls.ll test checks. The commit e497b12a69604b6d691312a30f6b86da4f18f7f8 went and regenerated all the checks lines in the Arm speculation-hardening-sls.ll test in a way that removed most of the important checks. This just resets them back to how they were before, with the single character fix to change: ; NOHARDENARM: {{bxge lr$}} to ; NOHARDENARM: {{bxgt lr$}} Differential Revision: https://reviews.llvm.org/D111074
2021-10-05 17:51:18 +08:00
; HARDENTHUMB: bl {{__llvm_slsblr_thunk_thumb_r[0-9]+$}}
[ARM] Harden indirect calls against SLS To make sure that no barrier gets placed on the architectural execution path, each indirect call calling the function in register rN, it gets transformed to a direct call to __llvm_slsblr_thunk_mode_rN. mode is either arm or thumb, depending on the mode of where the indirect call happens. The llvm_slsblr_thunk_mode_rN thunk contains: bx rN <speculation barrier> Therefore, the indirect call gets split into 2; one direct call and one indirect jump. 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 r12 on function calls, the above code transformation is not correct in case a linker does so. Similarly, the transformation is not correct when register lr is used. Avoiding r12/lr being used is done in a follow-on patch to make reviewing this code easier. Differential Revision: https://reviews.llvm.org/D92468
2020-11-21 00:11:17 +08:00
store i32 %call, i32* @b, align 4
ret void
[ARM] Reset speculation-hardening-sls.ll test checks. The commit e497b12a69604b6d691312a30f6b86da4f18f7f8 went and regenerated all the checks lines in the Arm speculation-hardening-sls.ll test in a way that removed most of the important checks. This just resets them back to how they were before, with the single character fix to change: ; NOHARDENARM: {{bxge lr$}} to ; NOHARDENARM: {{bxgt lr$}} Differential Revision: https://reviews.llvm.org/D111074
2021-10-05 17:51:18 +08:00
; CHECK: .Lfunc_end
[ARM] Harden indirect calls against SLS To make sure that no barrier gets placed on the architectural execution path, each indirect call calling the function in register rN, it gets transformed to a direct call to __llvm_slsblr_thunk_mode_rN. mode is either arm or thumb, depending on the mode of where the indirect call happens. The llvm_slsblr_thunk_mode_rN thunk contains: bx rN <speculation barrier> Therefore, the indirect call gets split into 2; one direct call and one indirect jump. 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 r12 on function calls, the above code transformation is not correct in case a linker does so. Similarly, the transformation is not correct when register lr is used. Avoiding r12/lr being used is done in a follow-on patch to make reviewing this code easier. Differential Revision: https://reviews.llvm.org/D92468
2020-11-21 00:11:17 +08:00
}
[ARM] harden-sls-blr: avoid r12 and lr in indirect calls. As a linker is allowed to clobber r12 on function calls, the code transformation that hardens indirect calls is not correct in case a linker does so. Similarly, the transformation is not correct when register lr is used. This patch makes sure that r12 or lr are not used for indirect calls when harden-sls-blr is enabled. Differential Revision: https://reviews.llvm.org/D92469
2020-11-26 21:45:37 +08:00
; Verify that neither r12 nor lr are used as registers in indirect call
; instructions when the sls-hardening-blr mitigation is enabled, as
; (a) a linker is allowed to clobber r12 on calls, and
; (b) the hardening transformation isn't correct if lr is the register holding
; the address of the function called.
define i32 @check_r12(i32 ()** %fp) {
entry:
[ARM] Reset speculation-hardening-sls.ll test checks. The commit e497b12a69604b6d691312a30f6b86da4f18f7f8 went and regenerated all the checks lines in the Arm speculation-hardening-sls.ll test in a way that removed most of the important checks. This just resets them back to how they were before, with the single character fix to change: ; NOHARDENARM: {{bxge lr$}} to ; NOHARDENARM: {{bxgt lr$}} Differential Revision: https://reviews.llvm.org/D111074
2021-10-05 17:51:18 +08:00
; CHECK-LABEL: check_r12:
[ARM] harden-sls-blr: avoid r12 and lr in indirect calls. As a linker is allowed to clobber r12 on function calls, the code transformation that hardens indirect calls is not correct in case a linker does so. Similarly, the transformation is not correct when register lr is used. This patch makes sure that r12 or lr are not used for indirect calls when harden-sls-blr is enabled. Differential Revision: https://reviews.llvm.org/D92469
2020-11-26 21:45:37 +08:00
%f = load i32 ()*, i32 ()** %fp, align 4
; Force f to be moved into r12
%r12_f = tail call i32 ()* asm "add $0, $1, #0", "={r12},{r12}"(i32 ()* %f) nounwind
%call = call i32 %r12_f()
[ARM] Reset speculation-hardening-sls.ll test checks. The commit e497b12a69604b6d691312a30f6b86da4f18f7f8 went and regenerated all the checks lines in the Arm speculation-hardening-sls.ll test in a way that removed most of the important checks. This just resets them back to how they were before, with the single character fix to change: ; NOHARDENARM: {{bxge lr$}} to ; NOHARDENARM: {{bxgt lr$}} Differential Revision: https://reviews.llvm.org/D111074
2021-10-05 17:51:18 +08:00
; NOHARDENARM: blx r12
; NOHARDENTHUMB: blx r12
; HARDEN-NOT: bl {{__llvm_slsblr_thunk_(arm|thumb)_r12}}
[ARM] harden-sls-blr: avoid r12 and lr in indirect calls. As a linker is allowed to clobber r12 on function calls, the code transformation that hardens indirect calls is not correct in case a linker does so. Similarly, the transformation is not correct when register lr is used. This patch makes sure that r12 or lr are not used for indirect calls when harden-sls-blr is enabled. Differential Revision: https://reviews.llvm.org/D92469
2020-11-26 21:45:37 +08:00
ret i32 %call
[ARM] Reset speculation-hardening-sls.ll test checks. The commit e497b12a69604b6d691312a30f6b86da4f18f7f8 went and regenerated all the checks lines in the Arm speculation-hardening-sls.ll test in a way that removed most of the important checks. This just resets them back to how they were before, with the single character fix to change: ; NOHARDENARM: {{bxge lr$}} to ; NOHARDENARM: {{bxgt lr$}} Differential Revision: https://reviews.llvm.org/D111074
2021-10-05 17:51:18 +08:00
; CHECK: .Lfunc_end
[ARM] harden-sls-blr: avoid r12 and lr in indirect calls. As a linker is allowed to clobber r12 on function calls, the code transformation that hardens indirect calls is not correct in case a linker does so. Similarly, the transformation is not correct when register lr is used. This patch makes sure that r12 or lr are not used for indirect calls when harden-sls-blr is enabled. Differential Revision: https://reviews.llvm.org/D92469
2020-11-26 21:45:37 +08:00
}
define i32 @check_lr(i32 ()** %fp) {
entry:
[ARM] Reset speculation-hardening-sls.ll test checks. The commit e497b12a69604b6d691312a30f6b86da4f18f7f8 went and regenerated all the checks lines in the Arm speculation-hardening-sls.ll test in a way that removed most of the important checks. This just resets them back to how they were before, with the single character fix to change: ; NOHARDENARM: {{bxge lr$}} to ; NOHARDENARM: {{bxgt lr$}} Differential Revision: https://reviews.llvm.org/D111074
2021-10-05 17:51:18 +08:00
; CHECK-LABEL: check_lr:
[ARM] harden-sls-blr: avoid r12 and lr in indirect calls. As a linker is allowed to clobber r12 on function calls, the code transformation that hardens indirect calls is not correct in case a linker does so. Similarly, the transformation is not correct when register lr is used. This patch makes sure that r12 or lr are not used for indirect calls when harden-sls-blr is enabled. Differential Revision: https://reviews.llvm.org/D92469
2020-11-26 21:45:37 +08:00
%f = load i32 ()*, i32 ()** %fp, align 4
; Force f to be moved into lr
%lr_f = tail call i32 ()* asm "add $0, $1, #0", "={lr},{lr}"(i32 ()* %f) nounwind
%call = call i32 %lr_f()
[ARM] Reset speculation-hardening-sls.ll test checks. The commit e497b12a69604b6d691312a30f6b86da4f18f7f8 went and regenerated all the checks lines in the Arm speculation-hardening-sls.ll test in a way that removed most of the important checks. This just resets them back to how they were before, with the single character fix to change: ; NOHARDENARM: {{bxge lr$}} to ; NOHARDENARM: {{bxgt lr$}} Differential Revision: https://reviews.llvm.org/D111074
2021-10-05 17:51:18 +08:00
; NOHARDENARM: blx lr
; NOHARDENTHUMB: blx lr
; HARDEN-NOT: bl {{__llvm_slsblr_thunk_(arm|thumb)_lr}}
[ARM] harden-sls-blr: avoid r12 and lr in indirect calls. As a linker is allowed to clobber r12 on function calls, the code transformation that hardens indirect calls is not correct in case a linker does so. Similarly, the transformation is not correct when register lr is used. This patch makes sure that r12 or lr are not used for indirect calls when harden-sls-blr is enabled. Differential Revision: https://reviews.llvm.org/D92469
2020-11-26 21:45:37 +08:00
ret i32 %call
[ARM] Reset speculation-hardening-sls.ll test checks. The commit e497b12a69604b6d691312a30f6b86da4f18f7f8 went and regenerated all the checks lines in the Arm speculation-hardening-sls.ll test in a way that removed most of the important checks. This just resets them back to how they were before, with the single character fix to change: ; NOHARDENARM: {{bxge lr$}} to ; NOHARDENARM: {{bxgt lr$}} Differential Revision: https://reviews.llvm.org/D111074
2021-10-05 17:51:18 +08:00
; CHECK: .Lfunc_end
[ARM] harden-sls-blr: avoid r12 and lr in indirect calls. As a linker is allowed to clobber r12 on function calls, the code transformation that hardens indirect calls is not correct in case a linker does so. Similarly, the transformation is not correct when register lr is used. This patch makes sure that r12 or lr are not used for indirect calls when harden-sls-blr is enabled. Differential Revision: https://reviews.llvm.org/D92469
2020-11-26 21:45:37 +08:00
}
; Verify that even when sls-harden-blr is enabled, "blx r12" is still an
; instruction that is accepted by the inline assembler
define void @verify_inline_asm_blx_r12(void ()* %g) {
entry:
[ARM] Reset speculation-hardening-sls.ll test checks. The commit e497b12a69604b6d691312a30f6b86da4f18f7f8 went and regenerated all the checks lines in the Arm speculation-hardening-sls.ll test in a way that removed most of the important checks. This just resets them back to how they were before, with the single character fix to change: ; NOHARDENARM: {{bxge lr$}} to ; NOHARDENARM: {{bxgt lr$}} Differential Revision: https://reviews.llvm.org/D111074
2021-10-05 17:51:18 +08:00
; CHECK-LABEL: verify_inline_asm_blx_r12:
[ARM] harden-sls-blr: avoid r12 and lr in indirect calls. As a linker is allowed to clobber r12 on function calls, the code transformation that hardens indirect calls is not correct in case a linker does so. Similarly, the transformation is not correct when register lr is used. This patch makes sure that r12 or lr are not used for indirect calls when harden-sls-blr is enabled. Differential Revision: https://reviews.llvm.org/D92469
2020-11-26 21:45:37 +08:00
%0 = bitcast void ()* %g to i8*
tail call void asm sideeffect "blx $0", "{r12}"(i8* %0) nounwind
[ARM] Reset speculation-hardening-sls.ll test checks. The commit e497b12a69604b6d691312a30f6b86da4f18f7f8 went and regenerated all the checks lines in the Arm speculation-hardening-sls.ll test in a way that removed most of the important checks. This just resets them back to how they were before, with the single character fix to change: ; NOHARDENARM: {{bxge lr$}} to ; NOHARDENARM: {{bxgt lr$}} Differential Revision: https://reviews.llvm.org/D111074
2021-10-05 17:51:18 +08:00
; CHECK: blx r12
[ARM] harden-sls-blr: avoid r12 and lr in indirect calls. As a linker is allowed to clobber r12 on function calls, the code transformation that hardens indirect calls is not correct in case a linker does so. Similarly, the transformation is not correct when register lr is used. This patch makes sure that r12 or lr are not used for indirect calls when harden-sls-blr is enabled. Differential Revision: https://reviews.llvm.org/D92469
2020-11-26 21:45:37 +08:00
ret void
[ARM] Reset speculation-hardening-sls.ll test checks. The commit e497b12a69604b6d691312a30f6b86da4f18f7f8 went and regenerated all the checks lines in the Arm speculation-hardening-sls.ll test in a way that removed most of the important checks. This just resets them back to how they were before, with the single character fix to change: ; NOHARDENARM: {{bxge lr$}} to ; NOHARDENARM: {{bxgt lr$}} Differential Revision: https://reviews.llvm.org/D111074
2021-10-05 17:51:18 +08:00
; CHECK: {{bx lr$}}
; ISBDSB-NEXT: dsb sy
; ISBDSB-NEXT: isb
; SB-NEXT: {{ sb$}}
; CHECK: .Lfunc_end
[ARM] harden-sls-blr: avoid r12 and lr in indirect calls. As a linker is allowed to clobber r12 on function calls, the code transformation that hardens indirect calls is not correct in case a linker does so. Similarly, the transformation is not correct when register lr is used. This patch makes sure that r12 or lr are not used for indirect calls when harden-sls-blr is enabled. Differential Revision: https://reviews.llvm.org/D92469
2020-11-26 21:45:37 +08:00
}
[ARM][AArch64] SLSHardening: make non-comdat thunks possible Linker scripts might not handle COMDAT sections. SLSHardeing adds new section for each __llvm_slsblr_thunk_xN. This new option allows the generation of the thunks into the normal text section to handle these exceptional cases. ,comdat or ,noncomdat can be added to harden-sls to control the codegen. -mharden-sls=[all|retbr|blr],nocomdat. Reviewed By: kristof.beyls Differential Revision: https://reviews.llvm.org/D100546
2021-05-20 23:06:43 +08:00
; HARDEN-COMDAT: .section {{.text.__llvm_slsblr_thunk_(arm|thumb)_r5}}
; HARDEN-COMDAT: .hidden {{__llvm_slsblr_thunk_(arm|thumb)_r5}}
; HARDEN-COMDAT: .weak {{__llvm_slsblr_thunk_(arm|thumb)_r5}}
; HARDEN-COMDAT: .type {{__llvm_slsblr_thunk_(arm|thumb)_r5}},%function
; HARDEN-COMDAT-OFF-NOT: .section {{.text.__llvm_slsblr_thunk_(arm|thumb)_r5}}
; HARDEN-COMDAT-OFF-NOT: .hidden {{__llvm_slsblr_thunk_(arm|thumb)_r5}}
; HARDEN-COMDAT-OFF-NOT: .weak {{__llvm_slsblr_thunk_(arm|thumb)_r5}}
; HARDEN-COMDAT-OFF: .type {{__llvm_slsblr_thunk_(arm|thumb)_r5}},%function
[ARM] harden-sls-blr: avoid r12 and lr in indirect calls. As a linker is allowed to clobber r12 on function calls, the code transformation that hardens indirect calls is not correct in case a linker does so. Similarly, the transformation is not correct when register lr is used. This patch makes sure that r12 or lr are not used for indirect calls when harden-sls-blr is enabled. Differential Revision: https://reviews.llvm.org/D92469
2020-11-26 21:45:37 +08:00
; HARDEN-label: {{__llvm_slsblr_thunk_(arm|thumb)_r5}}:
[ARM] Harden indirect calls against SLS To make sure that no barrier gets placed on the architectural execution path, each indirect call calling the function in register rN, it gets transformed to a direct call to __llvm_slsblr_thunk_mode_rN. mode is either arm or thumb, depending on the mode of where the indirect call happens. The llvm_slsblr_thunk_mode_rN thunk contains: bx rN <speculation barrier> Therefore, the indirect call gets split into 2; one direct call and one indirect jump. 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 r12 on function calls, the above code transformation is not correct in case a linker does so. Similarly, the transformation is not correct when register lr is used. Avoiding r12/lr being used is done in a follow-on patch to make reviewing this code easier. Differential Revision: https://reviews.llvm.org/D92468
2020-11-21 00:11:17 +08:00
; HARDEN: bx r5
; ISBDSB-NEXT: dsb sy
; ISBDSB-NEXT: isb
; SB-NEXT: dsb sy
; SB-NEXT: isb
; HARDEN-NEXT: .Lfunc_end
[ARM] harden-sls-blr: avoid r12 and lr in indirect calls. As a linker is allowed to clobber r12 on function calls, the code transformation that hardens indirect calls is not correct in case a linker does so. Similarly, the transformation is not correct when register lr is used. This patch makes sure that r12 or lr are not used for indirect calls when harden-sls-blr is enabled. Differential Revision: https://reviews.llvm.org/D92469
2020-11-26 21:45:37 +08:00