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/X86/speculative-load-hardening-...

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

486 lines
18 KiB
LLVM
Raw Normal View History

[x86/SLH] Teach SLH to harden against the "ret2spec" attack by implementing the proposed mitigation technique described in the original design document. The idea is to check after calls that the return address used to arrive at that location is in fact the correct address. In the event of a mis-predicted return which reaches a *valid* return but not the *correct* return, this will detect the mismatch much like it would a mispredicted conditional branch. This is the last published attack vector that I am aware of in the Spectre v1 space which is not mitigated by SLH+retpolines. However, don't read *too* much into that: this is an area of ongoing research where we expect more issues to be discovered in the future, and it also makes no attempt to mitigate Spectre v4. Still, this is an important completeness bar for SLH. The change here is of course delightfully simple. It was predicated on cutting support for post-instruction symbols into LLVM which was not at all simple. Many thanks to Hal Finkel, Reid Kleckner, and Justin Bogner who helped me figure out how to do a bunch of the complex changes involved there. Differential Revision: https://reviews.llvm.org/D50837 llvm-svn: 341358
2018-09-04 18:59:10 +08:00
; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
; RUN: llc < %s -mtriple=x86_64-unknown-linux-gnu -x86-speculative-load-hardening | FileCheck %s --check-prefix=X64-NOPIC
; RUN: llc < %s -mtriple=x86_64-unknown-linux-gnu -x86-speculative-load-hardening -code-model medium | FileCheck %s --check-prefix=X64-NOPIC-MCM
; RUN: llc < %s -mtriple=x86_64-unknown-linux-gnu -x86-speculative-load-hardening -relocation-model pic | FileCheck %s --check-prefix=X64-PIC
;
; FIXME: Add support for 32-bit.
declare void @f()
define i32 @test_calls_and_rets(i32 *%ptr) nounwind {
; X64-NOPIC-LABEL: test_calls_and_rets:
; X64-NOPIC: # %bb.0: # %entry
; X64-NOPIC-NEXT: pushq %rbp
; X64-NOPIC-NEXT: pushq %r14
; X64-NOPIC-NEXT: pushq %rbx
; X64-NOPIC-NEXT: movq %rsp, %rax
; X64-NOPIC-NEXT: movq %rdi, %rbx
; X64-NOPIC-NEXT: movq $-1, %r14
; X64-NOPIC-NEXT: sarq $63, %rax
; X64-NOPIC-NEXT: shlq $47, %rax
; X64-NOPIC-NEXT: orq %rax, %rsp
; X64-NOPIC-NEXT: callq f
; X64-NOPIC-NEXT: .Lslh_ret_addr0:
; X64-NOPIC-NEXT: movq %rsp, %rax
; X64-NOPIC-NEXT: movq -{{[0-9]+}}(%rsp), %rcx
; X64-NOPIC-NEXT: sarq $63, %rax
; X64-NOPIC-NEXT: cmpq $.Lslh_ret_addr0, %rcx
; X64-NOPIC-NEXT: cmovneq %r14, %rax
; X64-NOPIC-NEXT: movl (%rbx), %ebp
; X64-NOPIC-NEXT: shlq $47, %rax
; X64-NOPIC-NEXT: orq %rax, %rsp
; X64-NOPIC-NEXT: callq f
; X64-NOPIC-NEXT: .Lslh_ret_addr1:
; X64-NOPIC-NEXT: movq %rsp, %rcx
; X64-NOPIC-NEXT: movq -{{[0-9]+}}(%rsp), %rax
; X64-NOPIC-NEXT: sarq $63, %rcx
; X64-NOPIC-NEXT: cmpq $.Lslh_ret_addr1, %rax
; X64-NOPIC-NEXT: cmovneq %r14, %rcx
; X64-NOPIC-NEXT: addl (%rbx), %ebp
; X64-NOPIC-NEXT: orl %ecx, %ebp
; X64-NOPIC-NEXT: shlq $47, %rcx
; X64-NOPIC-NEXT: movl %ebp, %eax
; X64-NOPIC-NEXT: orq %rcx, %rsp
; X64-NOPIC-NEXT: popq %rbx
; X64-NOPIC-NEXT: popq %r14
; X64-NOPIC-NEXT: popq %rbp
; X64-NOPIC-NEXT: retq
;
; X64-NOPIC-MCM-LABEL: test_calls_and_rets:
; X64-NOPIC-MCM: # %bb.0: # %entry
; X64-NOPIC-MCM-NEXT: pushq %rbp
; X64-NOPIC-MCM-NEXT: pushq %r14
; X64-NOPIC-MCM-NEXT: pushq %rbx
; X64-NOPIC-MCM-NEXT: movq %rsp, %rax
; X64-NOPIC-MCM-NEXT: movq %rdi, %rbx
; X64-NOPIC-MCM-NEXT: movq $-1, %r14
; X64-NOPIC-MCM-NEXT: sarq $63, %rax
; X64-NOPIC-MCM-NEXT: shlq $47, %rax
; X64-NOPIC-MCM-NEXT: orq %rax, %rsp
; X64-NOPIC-MCM-NEXT: callq f
; X64-NOPIC-MCM-NEXT: .Lslh_ret_addr0:
; X64-NOPIC-MCM-NEXT: movq %rsp, %rax
; X64-NOPIC-MCM-NEXT: movq -{{[0-9]+}}(%rsp), %rcx
; X64-NOPIC-MCM-NEXT: sarq $63, %rax
[SLH] Regenerate tests with --no_x86_scrub_rip to restore the higher fidelity checking of RIP-based references to basic blocks and other labels. These labels are super important for SLH tests so we should keep them readable in the test cases. llvm-svn: 348373
2018-12-05 23:41:13 +08:00
; X64-NOPIC-MCM-NEXT: leaq .Lslh_ret_addr0(%rip), %rdx
[x86/SLH] Teach SLH to harden against the "ret2spec" attack by implementing the proposed mitigation technique described in the original design document. The idea is to check after calls that the return address used to arrive at that location is in fact the correct address. In the event of a mis-predicted return which reaches a *valid* return but not the *correct* return, this will detect the mismatch much like it would a mispredicted conditional branch. This is the last published attack vector that I am aware of in the Spectre v1 space which is not mitigated by SLH+retpolines. However, don't read *too* much into that: this is an area of ongoing research where we expect more issues to be discovered in the future, and it also makes no attempt to mitigate Spectre v4. Still, this is an important completeness bar for SLH. The change here is of course delightfully simple. It was predicated on cutting support for post-instruction symbols into LLVM which was not at all simple. Many thanks to Hal Finkel, Reid Kleckner, and Justin Bogner who helped me figure out how to do a bunch of the complex changes involved there. Differential Revision: https://reviews.llvm.org/D50837 llvm-svn: 341358
2018-09-04 18:59:10 +08:00
; X64-NOPIC-MCM-NEXT: cmpq %rdx, %rcx
; X64-NOPIC-MCM-NEXT: cmovneq %r14, %rax
; X64-NOPIC-MCM-NEXT: movl (%rbx), %ebp
; X64-NOPIC-MCM-NEXT: shlq $47, %rax
; X64-NOPIC-MCM-NEXT: orq %rax, %rsp
; X64-NOPIC-MCM-NEXT: callq f
; X64-NOPIC-MCM-NEXT: .Lslh_ret_addr1:
; X64-NOPIC-MCM-NEXT: movq %rsp, %rcx
; X64-NOPIC-MCM-NEXT: movq -{{[0-9]+}}(%rsp), %rax
; X64-NOPIC-MCM-NEXT: sarq $63, %rcx
[SLH] Regenerate tests with --no_x86_scrub_rip to restore the higher fidelity checking of RIP-based references to basic blocks and other labels. These labels are super important for SLH tests so we should keep them readable in the test cases. llvm-svn: 348373
2018-12-05 23:41:13 +08:00
; X64-NOPIC-MCM-NEXT: leaq .Lslh_ret_addr1(%rip), %rdx
[x86/SLH] Teach SLH to harden against the "ret2spec" attack by implementing the proposed mitigation technique described in the original design document. The idea is to check after calls that the return address used to arrive at that location is in fact the correct address. In the event of a mis-predicted return which reaches a *valid* return but not the *correct* return, this will detect the mismatch much like it would a mispredicted conditional branch. This is the last published attack vector that I am aware of in the Spectre v1 space which is not mitigated by SLH+retpolines. However, don't read *too* much into that: this is an area of ongoing research where we expect more issues to be discovered in the future, and it also makes no attempt to mitigate Spectre v4. Still, this is an important completeness bar for SLH. The change here is of course delightfully simple. It was predicated on cutting support for post-instruction symbols into LLVM which was not at all simple. Many thanks to Hal Finkel, Reid Kleckner, and Justin Bogner who helped me figure out how to do a bunch of the complex changes involved there. Differential Revision: https://reviews.llvm.org/D50837 llvm-svn: 341358
2018-09-04 18:59:10 +08:00
; X64-NOPIC-MCM-NEXT: cmpq %rdx, %rax
; X64-NOPIC-MCM-NEXT: cmovneq %r14, %rcx
; X64-NOPIC-MCM-NEXT: addl (%rbx), %ebp
; X64-NOPIC-MCM-NEXT: orl %ecx, %ebp
; X64-NOPIC-MCM-NEXT: shlq $47, %rcx
; X64-NOPIC-MCM-NEXT: movl %ebp, %eax
; X64-NOPIC-MCM-NEXT: orq %rcx, %rsp
; X64-NOPIC-MCM-NEXT: popq %rbx
; X64-NOPIC-MCM-NEXT: popq %r14
; X64-NOPIC-MCM-NEXT: popq %rbp
; X64-NOPIC-MCM-NEXT: retq
;
; X64-PIC-LABEL: test_calls_and_rets:
; X64-PIC: # %bb.0: # %entry
; X64-PIC-NEXT: pushq %rbp
; X64-PIC-NEXT: pushq %r14
; X64-PIC-NEXT: pushq %rbx
; X64-PIC-NEXT: movq %rsp, %rax
; X64-PIC-NEXT: movq %rdi, %rbx
; X64-PIC-NEXT: movq $-1, %r14
; X64-PIC-NEXT: sarq $63, %rax
; X64-PIC-NEXT: shlq $47, %rax
; X64-PIC-NEXT: orq %rax, %rsp
; X64-PIC-NEXT: callq f@PLT
; X64-PIC-NEXT: .Lslh_ret_addr0:
; X64-PIC-NEXT: movq %rsp, %rax
; X64-PIC-NEXT: movq -{{[0-9]+}}(%rsp), %rcx
; X64-PIC-NEXT: sarq $63, %rax
[SLH] Regenerate tests with --no_x86_scrub_rip to restore the higher fidelity checking of RIP-based references to basic blocks and other labels. These labels are super important for SLH tests so we should keep them readable in the test cases. llvm-svn: 348373
2018-12-05 23:41:13 +08:00
; X64-PIC-NEXT: leaq .Lslh_ret_addr0(%rip), %rdx
[x86/SLH] Teach SLH to harden against the "ret2spec" attack by implementing the proposed mitigation technique described in the original design document. The idea is to check after calls that the return address used to arrive at that location is in fact the correct address. In the event of a mis-predicted return which reaches a *valid* return but not the *correct* return, this will detect the mismatch much like it would a mispredicted conditional branch. This is the last published attack vector that I am aware of in the Spectre v1 space which is not mitigated by SLH+retpolines. However, don't read *too* much into that: this is an area of ongoing research where we expect more issues to be discovered in the future, and it also makes no attempt to mitigate Spectre v4. Still, this is an important completeness bar for SLH. The change here is of course delightfully simple. It was predicated on cutting support for post-instruction symbols into LLVM which was not at all simple. Many thanks to Hal Finkel, Reid Kleckner, and Justin Bogner who helped me figure out how to do a bunch of the complex changes involved there. Differential Revision: https://reviews.llvm.org/D50837 llvm-svn: 341358
2018-09-04 18:59:10 +08:00
; X64-PIC-NEXT: cmpq %rdx, %rcx
; X64-PIC-NEXT: cmovneq %r14, %rax
; X64-PIC-NEXT: movl (%rbx), %ebp
; X64-PIC-NEXT: shlq $47, %rax
; X64-PIC-NEXT: orq %rax, %rsp
; X64-PIC-NEXT: callq f@PLT
; X64-PIC-NEXT: .Lslh_ret_addr1:
; X64-PIC-NEXT: movq %rsp, %rcx
; X64-PIC-NEXT: movq -{{[0-9]+}}(%rsp), %rax
; X64-PIC-NEXT: sarq $63, %rcx
[SLH] Regenerate tests with --no_x86_scrub_rip to restore the higher fidelity checking of RIP-based references to basic blocks and other labels. These labels are super important for SLH tests so we should keep them readable in the test cases. llvm-svn: 348373
2018-12-05 23:41:13 +08:00
; X64-PIC-NEXT: leaq .Lslh_ret_addr1(%rip), %rdx
[x86/SLH] Teach SLH to harden against the "ret2spec" attack by implementing the proposed mitigation technique described in the original design document. The idea is to check after calls that the return address used to arrive at that location is in fact the correct address. In the event of a mis-predicted return which reaches a *valid* return but not the *correct* return, this will detect the mismatch much like it would a mispredicted conditional branch. This is the last published attack vector that I am aware of in the Spectre v1 space which is not mitigated by SLH+retpolines. However, don't read *too* much into that: this is an area of ongoing research where we expect more issues to be discovered in the future, and it also makes no attempt to mitigate Spectre v4. Still, this is an important completeness bar for SLH. The change here is of course delightfully simple. It was predicated on cutting support for post-instruction symbols into LLVM which was not at all simple. Many thanks to Hal Finkel, Reid Kleckner, and Justin Bogner who helped me figure out how to do a bunch of the complex changes involved there. Differential Revision: https://reviews.llvm.org/D50837 llvm-svn: 341358
2018-09-04 18:59:10 +08:00
; X64-PIC-NEXT: cmpq %rdx, %rax
; X64-PIC-NEXT: cmovneq %r14, %rcx
; X64-PIC-NEXT: addl (%rbx), %ebp
; X64-PIC-NEXT: orl %ecx, %ebp
; X64-PIC-NEXT: shlq $47, %rcx
; X64-PIC-NEXT: movl %ebp, %eax
; X64-PIC-NEXT: orq %rcx, %rsp
; X64-PIC-NEXT: popq %rbx
; X64-PIC-NEXT: popq %r14
; X64-PIC-NEXT: popq %rbp
; X64-PIC-NEXT: retq
entry:
call void @f()
%x = load i32, i32* %ptr
call void @f()
%y = load i32, i32* %ptr
%z = add i32 %x, %y
ret i32 %z
}
define i32 @test_calls_and_rets_noredzone(i32 *%ptr) nounwind noredzone {
; X64-NOPIC-LABEL: test_calls_and_rets_noredzone:
; X64-NOPIC: # %bb.0: # %entry
; X64-NOPIC-NEXT: pushq %rbp
; X64-NOPIC-NEXT: pushq %r15
; X64-NOPIC-NEXT: pushq %r14
; X64-NOPIC-NEXT: pushq %rbx
; X64-NOPIC-NEXT: pushq %rax
; X64-NOPIC-NEXT: movq %rsp, %rax
; X64-NOPIC-NEXT: movq %rdi, %rbx
; X64-NOPIC-NEXT: movq $-1, %r14
; X64-NOPIC-NEXT: sarq $63, %rax
; X64-NOPIC-NEXT: shlq $47, %rax
; X64-NOPIC-NEXT: orq %rax, %rsp
; X64-NOPIC-NEXT: movq $.Lslh_ret_addr2, %rbp
; X64-NOPIC-NEXT: callq f
; X64-NOPIC-NEXT: .Lslh_ret_addr2:
; X64-NOPIC-NEXT: movq %rsp, %rax
; X64-NOPIC-NEXT: sarq $63, %rax
; X64-NOPIC-NEXT: cmpq $.Lslh_ret_addr2, %rbp
; X64-NOPIC-NEXT: cmovneq %r14, %rax
; X64-NOPIC-NEXT: movl (%rbx), %ebp
; X64-NOPIC-NEXT: shlq $47, %rax
; X64-NOPIC-NEXT: orq %rax, %rsp
; X64-NOPIC-NEXT: movq $.Lslh_ret_addr3, %r15
; X64-NOPIC-NEXT: callq f
; X64-NOPIC-NEXT: .Lslh_ret_addr3:
; X64-NOPIC-NEXT: movq %rsp, %rcx
; X64-NOPIC-NEXT: sarq $63, %rcx
; X64-NOPIC-NEXT: cmpq $.Lslh_ret_addr3, %r15
; X64-NOPIC-NEXT: cmovneq %r14, %rcx
; X64-NOPIC-NEXT: addl (%rbx), %ebp
; X64-NOPIC-NEXT: orl %ecx, %ebp
; X64-NOPIC-NEXT: shlq $47, %rcx
; X64-NOPIC-NEXT: movl %ebp, %eax
; X64-NOPIC-NEXT: orq %rcx, %rsp
; X64-NOPIC-NEXT: addq $8, %rsp
; X64-NOPIC-NEXT: popq %rbx
; X64-NOPIC-NEXT: popq %r14
; X64-NOPIC-NEXT: popq %r15
; X64-NOPIC-NEXT: popq %rbp
; X64-NOPIC-NEXT: retq
;
; X64-NOPIC-MCM-LABEL: test_calls_and_rets_noredzone:
; X64-NOPIC-MCM: # %bb.0: # %entry
; X64-NOPIC-MCM-NEXT: pushq %rbp
; X64-NOPIC-MCM-NEXT: pushq %r15
; X64-NOPIC-MCM-NEXT: pushq %r14
; X64-NOPIC-MCM-NEXT: pushq %rbx
; X64-NOPIC-MCM-NEXT: pushq %rax
; X64-NOPIC-MCM-NEXT: movq %rsp, %rax
; X64-NOPIC-MCM-NEXT: movq %rdi, %rbx
; X64-NOPIC-MCM-NEXT: movq $-1, %r14
; X64-NOPIC-MCM-NEXT: sarq $63, %rax
; X64-NOPIC-MCM-NEXT: shlq $47, %rax
; X64-NOPIC-MCM-NEXT: orq %rax, %rsp
[SLH] Regenerate tests with --no_x86_scrub_rip to restore the higher fidelity checking of RIP-based references to basic blocks and other labels. These labels are super important for SLH tests so we should keep them readable in the test cases. llvm-svn: 348373
2018-12-05 23:41:13 +08:00
; X64-NOPIC-MCM-NEXT: leaq .Lslh_ret_addr2(%rip), %rbp
[x86/SLH] Teach SLH to harden against the "ret2spec" attack by implementing the proposed mitigation technique described in the original design document. The idea is to check after calls that the return address used to arrive at that location is in fact the correct address. In the event of a mis-predicted return which reaches a *valid* return but not the *correct* return, this will detect the mismatch much like it would a mispredicted conditional branch. This is the last published attack vector that I am aware of in the Spectre v1 space which is not mitigated by SLH+retpolines. However, don't read *too* much into that: this is an area of ongoing research where we expect more issues to be discovered in the future, and it also makes no attempt to mitigate Spectre v4. Still, this is an important completeness bar for SLH. The change here is of course delightfully simple. It was predicated on cutting support for post-instruction symbols into LLVM which was not at all simple. Many thanks to Hal Finkel, Reid Kleckner, and Justin Bogner who helped me figure out how to do a bunch of the complex changes involved there. Differential Revision: https://reviews.llvm.org/D50837 llvm-svn: 341358
2018-09-04 18:59:10 +08:00
; X64-NOPIC-MCM-NEXT: callq f
; X64-NOPIC-MCM-NEXT: .Lslh_ret_addr2:
; X64-NOPIC-MCM-NEXT: movq %rsp, %rax
; X64-NOPIC-MCM-NEXT: sarq $63, %rax
[SLH] Regenerate tests with --no_x86_scrub_rip to restore the higher fidelity checking of RIP-based references to basic blocks and other labels. These labels are super important for SLH tests so we should keep them readable in the test cases. llvm-svn: 348373
2018-12-05 23:41:13 +08:00
; X64-NOPIC-MCM-NEXT: leaq .Lslh_ret_addr2(%rip), %rcx
[x86/SLH] Teach SLH to harden against the "ret2spec" attack by implementing the proposed mitigation technique described in the original design document. The idea is to check after calls that the return address used to arrive at that location is in fact the correct address. In the event of a mis-predicted return which reaches a *valid* return but not the *correct* return, this will detect the mismatch much like it would a mispredicted conditional branch. This is the last published attack vector that I am aware of in the Spectre v1 space which is not mitigated by SLH+retpolines. However, don't read *too* much into that: this is an area of ongoing research where we expect more issues to be discovered in the future, and it also makes no attempt to mitigate Spectre v4. Still, this is an important completeness bar for SLH. The change here is of course delightfully simple. It was predicated on cutting support for post-instruction symbols into LLVM which was not at all simple. Many thanks to Hal Finkel, Reid Kleckner, and Justin Bogner who helped me figure out how to do a bunch of the complex changes involved there. Differential Revision: https://reviews.llvm.org/D50837 llvm-svn: 341358
2018-09-04 18:59:10 +08:00
; X64-NOPIC-MCM-NEXT: cmpq %rcx, %rbp
; X64-NOPIC-MCM-NEXT: cmovneq %r14, %rax
; X64-NOPIC-MCM-NEXT: movl (%rbx), %ebp
; X64-NOPIC-MCM-NEXT: shlq $47, %rax
; X64-NOPIC-MCM-NEXT: orq %rax, %rsp
[SLH] Regenerate tests with --no_x86_scrub_rip to restore the higher fidelity checking of RIP-based references to basic blocks and other labels. These labels are super important for SLH tests so we should keep them readable in the test cases. llvm-svn: 348373
2018-12-05 23:41:13 +08:00
; X64-NOPIC-MCM-NEXT: leaq .Lslh_ret_addr3(%rip), %r15
[x86/SLH] Teach SLH to harden against the "ret2spec" attack by implementing the proposed mitigation technique described in the original design document. The idea is to check after calls that the return address used to arrive at that location is in fact the correct address. In the event of a mis-predicted return which reaches a *valid* return but not the *correct* return, this will detect the mismatch much like it would a mispredicted conditional branch. This is the last published attack vector that I am aware of in the Spectre v1 space which is not mitigated by SLH+retpolines. However, don't read *too* much into that: this is an area of ongoing research where we expect more issues to be discovered in the future, and it also makes no attempt to mitigate Spectre v4. Still, this is an important completeness bar for SLH. The change here is of course delightfully simple. It was predicated on cutting support for post-instruction symbols into LLVM which was not at all simple. Many thanks to Hal Finkel, Reid Kleckner, and Justin Bogner who helped me figure out how to do a bunch of the complex changes involved there. Differential Revision: https://reviews.llvm.org/D50837 llvm-svn: 341358
2018-09-04 18:59:10 +08:00
; X64-NOPIC-MCM-NEXT: callq f
; X64-NOPIC-MCM-NEXT: .Lslh_ret_addr3:
; X64-NOPIC-MCM-NEXT: movq %rsp, %rcx
; X64-NOPIC-MCM-NEXT: sarq $63, %rcx
[SLH] Regenerate tests with --no_x86_scrub_rip to restore the higher fidelity checking of RIP-based references to basic blocks and other labels. These labels are super important for SLH tests so we should keep them readable in the test cases. llvm-svn: 348373
2018-12-05 23:41:13 +08:00
; X64-NOPIC-MCM-NEXT: leaq .Lslh_ret_addr3(%rip), %rax
[x86/SLH] Teach SLH to harden against the "ret2spec" attack by implementing the proposed mitigation technique described in the original design document. The idea is to check after calls that the return address used to arrive at that location is in fact the correct address. In the event of a mis-predicted return which reaches a *valid* return but not the *correct* return, this will detect the mismatch much like it would a mispredicted conditional branch. This is the last published attack vector that I am aware of in the Spectre v1 space which is not mitigated by SLH+retpolines. However, don't read *too* much into that: this is an area of ongoing research where we expect more issues to be discovered in the future, and it also makes no attempt to mitigate Spectre v4. Still, this is an important completeness bar for SLH. The change here is of course delightfully simple. It was predicated on cutting support for post-instruction symbols into LLVM which was not at all simple. Many thanks to Hal Finkel, Reid Kleckner, and Justin Bogner who helped me figure out how to do a bunch of the complex changes involved there. Differential Revision: https://reviews.llvm.org/D50837 llvm-svn: 341358
2018-09-04 18:59:10 +08:00
; X64-NOPIC-MCM-NEXT: cmpq %rax, %r15
; X64-NOPIC-MCM-NEXT: cmovneq %r14, %rcx
; X64-NOPIC-MCM-NEXT: addl (%rbx), %ebp
; X64-NOPIC-MCM-NEXT: orl %ecx, %ebp
; X64-NOPIC-MCM-NEXT: shlq $47, %rcx
; X64-NOPIC-MCM-NEXT: movl %ebp, %eax
; X64-NOPIC-MCM-NEXT: orq %rcx, %rsp
; X64-NOPIC-MCM-NEXT: addq $8, %rsp
; X64-NOPIC-MCM-NEXT: popq %rbx
; X64-NOPIC-MCM-NEXT: popq %r14
; X64-NOPIC-MCM-NEXT: popq %r15
; X64-NOPIC-MCM-NEXT: popq %rbp
; X64-NOPIC-MCM-NEXT: retq
;
; X64-PIC-LABEL: test_calls_and_rets_noredzone:
; X64-PIC: # %bb.0: # %entry
; X64-PIC-NEXT: pushq %rbp
; X64-PIC-NEXT: pushq %r15
; X64-PIC-NEXT: pushq %r14
; X64-PIC-NEXT: pushq %rbx
; X64-PIC-NEXT: pushq %rax
; X64-PIC-NEXT: movq %rsp, %rax
; X64-PIC-NEXT: movq %rdi, %rbx
; X64-PIC-NEXT: movq $-1, %r14
; X64-PIC-NEXT: sarq $63, %rax
; X64-PIC-NEXT: shlq $47, %rax
; X64-PIC-NEXT: orq %rax, %rsp
[SLH] Regenerate tests with --no_x86_scrub_rip to restore the higher fidelity checking of RIP-based references to basic blocks and other labels. These labels are super important for SLH tests so we should keep them readable in the test cases. llvm-svn: 348373
2018-12-05 23:41:13 +08:00
; X64-PIC-NEXT: leaq .Lslh_ret_addr2(%rip), %rbp
[x86/SLH] Teach SLH to harden against the "ret2spec" attack by implementing the proposed mitigation technique described in the original design document. The idea is to check after calls that the return address used to arrive at that location is in fact the correct address. In the event of a mis-predicted return which reaches a *valid* return but not the *correct* return, this will detect the mismatch much like it would a mispredicted conditional branch. This is the last published attack vector that I am aware of in the Spectre v1 space which is not mitigated by SLH+retpolines. However, don't read *too* much into that: this is an area of ongoing research where we expect more issues to be discovered in the future, and it also makes no attempt to mitigate Spectre v4. Still, this is an important completeness bar for SLH. The change here is of course delightfully simple. It was predicated on cutting support for post-instruction symbols into LLVM which was not at all simple. Many thanks to Hal Finkel, Reid Kleckner, and Justin Bogner who helped me figure out how to do a bunch of the complex changes involved there. Differential Revision: https://reviews.llvm.org/D50837 llvm-svn: 341358
2018-09-04 18:59:10 +08:00
; X64-PIC-NEXT: callq f@PLT
; X64-PIC-NEXT: .Lslh_ret_addr2:
; X64-PIC-NEXT: movq %rsp, %rax
; X64-PIC-NEXT: sarq $63, %rax
[SLH] Regenerate tests with --no_x86_scrub_rip to restore the higher fidelity checking of RIP-based references to basic blocks and other labels. These labels are super important for SLH tests so we should keep them readable in the test cases. llvm-svn: 348373
2018-12-05 23:41:13 +08:00
; X64-PIC-NEXT: leaq .Lslh_ret_addr2(%rip), %rcx
[x86/SLH] Teach SLH to harden against the "ret2spec" attack by implementing the proposed mitigation technique described in the original design document. The idea is to check after calls that the return address used to arrive at that location is in fact the correct address. In the event of a mis-predicted return which reaches a *valid* return but not the *correct* return, this will detect the mismatch much like it would a mispredicted conditional branch. This is the last published attack vector that I am aware of in the Spectre v1 space which is not mitigated by SLH+retpolines. However, don't read *too* much into that: this is an area of ongoing research where we expect more issues to be discovered in the future, and it also makes no attempt to mitigate Spectre v4. Still, this is an important completeness bar for SLH. The change here is of course delightfully simple. It was predicated on cutting support for post-instruction symbols into LLVM which was not at all simple. Many thanks to Hal Finkel, Reid Kleckner, and Justin Bogner who helped me figure out how to do a bunch of the complex changes involved there. Differential Revision: https://reviews.llvm.org/D50837 llvm-svn: 341358
2018-09-04 18:59:10 +08:00
; X64-PIC-NEXT: cmpq %rcx, %rbp
; X64-PIC-NEXT: cmovneq %r14, %rax
; X64-PIC-NEXT: movl (%rbx), %ebp
; X64-PIC-NEXT: shlq $47, %rax
; X64-PIC-NEXT: orq %rax, %rsp
[SLH] Regenerate tests with --no_x86_scrub_rip to restore the higher fidelity checking of RIP-based references to basic blocks and other labels. These labels are super important for SLH tests so we should keep them readable in the test cases. llvm-svn: 348373
2018-12-05 23:41:13 +08:00
; X64-PIC-NEXT: leaq .Lslh_ret_addr3(%rip), %r15
[x86/SLH] Teach SLH to harden against the "ret2spec" attack by implementing the proposed mitigation technique described in the original design document. The idea is to check after calls that the return address used to arrive at that location is in fact the correct address. In the event of a mis-predicted return which reaches a *valid* return but not the *correct* return, this will detect the mismatch much like it would a mispredicted conditional branch. This is the last published attack vector that I am aware of in the Spectre v1 space which is not mitigated by SLH+retpolines. However, don't read *too* much into that: this is an area of ongoing research where we expect more issues to be discovered in the future, and it also makes no attempt to mitigate Spectre v4. Still, this is an important completeness bar for SLH. The change here is of course delightfully simple. It was predicated on cutting support for post-instruction symbols into LLVM which was not at all simple. Many thanks to Hal Finkel, Reid Kleckner, and Justin Bogner who helped me figure out how to do a bunch of the complex changes involved there. Differential Revision: https://reviews.llvm.org/D50837 llvm-svn: 341358
2018-09-04 18:59:10 +08:00
; X64-PIC-NEXT: callq f@PLT
; X64-PIC-NEXT: .Lslh_ret_addr3:
; X64-PIC-NEXT: movq %rsp, %rcx
; X64-PIC-NEXT: sarq $63, %rcx
[SLH] Regenerate tests with --no_x86_scrub_rip to restore the higher fidelity checking of RIP-based references to basic blocks and other labels. These labels are super important for SLH tests so we should keep them readable in the test cases. llvm-svn: 348373
2018-12-05 23:41:13 +08:00
; X64-PIC-NEXT: leaq .Lslh_ret_addr3(%rip), %rax
[x86/SLH] Teach SLH to harden against the "ret2spec" attack by implementing the proposed mitigation technique described in the original design document. The idea is to check after calls that the return address used to arrive at that location is in fact the correct address. In the event of a mis-predicted return which reaches a *valid* return but not the *correct* return, this will detect the mismatch much like it would a mispredicted conditional branch. This is the last published attack vector that I am aware of in the Spectre v1 space which is not mitigated by SLH+retpolines. However, don't read *too* much into that: this is an area of ongoing research where we expect more issues to be discovered in the future, and it also makes no attempt to mitigate Spectre v4. Still, this is an important completeness bar for SLH. The change here is of course delightfully simple. It was predicated on cutting support for post-instruction symbols into LLVM which was not at all simple. Many thanks to Hal Finkel, Reid Kleckner, and Justin Bogner who helped me figure out how to do a bunch of the complex changes involved there. Differential Revision: https://reviews.llvm.org/D50837 llvm-svn: 341358
2018-09-04 18:59:10 +08:00
; X64-PIC-NEXT: cmpq %rax, %r15
; X64-PIC-NEXT: cmovneq %r14, %rcx
; X64-PIC-NEXT: addl (%rbx), %ebp
; X64-PIC-NEXT: orl %ecx, %ebp
; X64-PIC-NEXT: shlq $47, %rcx
; X64-PIC-NEXT: movl %ebp, %eax
; X64-PIC-NEXT: orq %rcx, %rsp
; X64-PIC-NEXT: addq $8, %rsp
; X64-PIC-NEXT: popq %rbx
; X64-PIC-NEXT: popq %r14
; X64-PIC-NEXT: popq %r15
; X64-PIC-NEXT: popq %rbp
; X64-PIC-NEXT: retq
entry:
call void @f()
%x = load i32, i32* %ptr
call void @f()
%y = load i32, i32* %ptr
%z = add i32 %x, %y
ret i32 %z
}
declare i32 @setjmp(i8* %env) returns_twice
declare i32 @sigsetjmp(i8* %env, i32 %savemask) returns_twice
declare i32 @__sigsetjmp(i8* %foo, i8* %bar, i32 %baz) returns_twice
define i32 @test_call_setjmp(i32 *%ptr) nounwind {
; X64-NOPIC-LABEL: test_call_setjmp:
; X64-NOPIC: # %bb.0: # %entry
; X64-NOPIC-NEXT: pushq %rbp
; X64-NOPIC-NEXT: pushq %r15
; X64-NOPIC-NEXT: pushq %r14
; X64-NOPIC-NEXT: pushq %r12
; X64-NOPIC-NEXT: pushq %rbx
; X64-NOPIC-NEXT: subq $16, %rsp
; X64-NOPIC-NEXT: movq %rsp, %rax
; X64-NOPIC-NEXT: movq %rdi, %rbx
; X64-NOPIC-NEXT: movq $-1, %r15
; X64-NOPIC-NEXT: sarq $63, %rax
; X64-NOPIC-NEXT: movq %rsp, %r14
; X64-NOPIC-NEXT: shlq $47, %rax
; X64-NOPIC-NEXT: movq %r14, %rdi
; X64-NOPIC-NEXT: orq %rax, %rsp
; X64-NOPIC-NEXT: movq $.Lslh_ret_addr4, %rbp
; X64-NOPIC-NEXT: callq setjmp
; X64-NOPIC-NEXT: .Lslh_ret_addr4:
; X64-NOPIC-NEXT: movq %rsp, %rax
; X64-NOPIC-NEXT: sarq $63, %rax
; X64-NOPIC-NEXT: cmpq $.Lslh_ret_addr4, %rbp
; X64-NOPIC-NEXT: cmovneq %r15, %rax
; X64-NOPIC-NEXT: movl (%rbx), %ebp
; X64-NOPIC-NEXT: shlq $47, %rax
; X64-NOPIC-NEXT: movq %r14, %rdi
Bias physical register immediate assignments The machine scheduler currently biases register copies to/from physical registers to be closer to their point of use / def to minimize their live ranges. This change extends this to also physical register assignments from immediate values. This causes a reduction in reduction in overall register pressure and minor reduction in spills and indirectly fixes an out-of-registers assertion (PR39391). Most test changes are from minor instruction reorderings and register name selection changes and direct consequences of that. Reviewers: MatzeB, qcolombet, myatsina, pcc Subscribers: nemanjai, jvesely, nhaehnle, eraman, hiraditya, javed.absar, arphaman, jfb, jsji, llvm-commits Differential Revision: https://reviews.llvm.org/D54218 llvm-svn: 346894
2018-11-15 05:11:53 +08:00
; X64-NOPIC-NEXT: movl $42, %esi
[x86/SLH] Teach SLH to harden against the "ret2spec" attack by implementing the proposed mitigation technique described in the original design document. The idea is to check after calls that the return address used to arrive at that location is in fact the correct address. In the event of a mis-predicted return which reaches a *valid* return but not the *correct* return, this will detect the mismatch much like it would a mispredicted conditional branch. This is the last published attack vector that I am aware of in the Spectre v1 space which is not mitigated by SLH+retpolines. However, don't read *too* much into that: this is an area of ongoing research where we expect more issues to be discovered in the future, and it also makes no attempt to mitigate Spectre v4. Still, this is an important completeness bar for SLH. The change here is of course delightfully simple. It was predicated on cutting support for post-instruction symbols into LLVM which was not at all simple. Many thanks to Hal Finkel, Reid Kleckner, and Justin Bogner who helped me figure out how to do a bunch of the complex changes involved there. Differential Revision: https://reviews.llvm.org/D50837 llvm-svn: 341358
2018-09-04 18:59:10 +08:00
; X64-NOPIC-NEXT: orq %rax, %rsp
; X64-NOPIC-NEXT: movq $.Lslh_ret_addr5, %r12
; X64-NOPIC-NEXT: callq sigsetjmp
; X64-NOPIC-NEXT: .Lslh_ret_addr5:
; X64-NOPIC-NEXT: movq %rsp, %rax
; X64-NOPIC-NEXT: sarq $63, %rax
; X64-NOPIC-NEXT: cmpq $.Lslh_ret_addr5, %r12
; X64-NOPIC-NEXT: cmovneq %r15, %rax
; X64-NOPIC-NEXT: addl (%rbx), %ebp
; X64-NOPIC-NEXT: shlq $47, %rax
; X64-NOPIC-NEXT: movq %r14, %rdi
; X64-NOPIC-NEXT: movq %r14, %rsi
Bias physical register immediate assignments The machine scheduler currently biases register copies to/from physical registers to be closer to their point of use / def to minimize their live ranges. This change extends this to also physical register assignments from immediate values. This causes a reduction in reduction in overall register pressure and minor reduction in spills and indirectly fixes an out-of-registers assertion (PR39391). Most test changes are from minor instruction reorderings and register name selection changes and direct consequences of that. Reviewers: MatzeB, qcolombet, myatsina, pcc Subscribers: nemanjai, jvesely, nhaehnle, eraman, hiraditya, javed.absar, arphaman, jfb, jsji, llvm-commits Differential Revision: https://reviews.llvm.org/D54218 llvm-svn: 346894
2018-11-15 05:11:53 +08:00
; X64-NOPIC-NEXT: movl $42, %edx
[x86/SLH] Teach SLH to harden against the "ret2spec" attack by implementing the proposed mitigation technique described in the original design document. The idea is to check after calls that the return address used to arrive at that location is in fact the correct address. In the event of a mis-predicted return which reaches a *valid* return but not the *correct* return, this will detect the mismatch much like it would a mispredicted conditional branch. This is the last published attack vector that I am aware of in the Spectre v1 space which is not mitigated by SLH+retpolines. However, don't read *too* much into that: this is an area of ongoing research where we expect more issues to be discovered in the future, and it also makes no attempt to mitigate Spectre v4. Still, this is an important completeness bar for SLH. The change here is of course delightfully simple. It was predicated on cutting support for post-instruction symbols into LLVM which was not at all simple. Many thanks to Hal Finkel, Reid Kleckner, and Justin Bogner who helped me figure out how to do a bunch of the complex changes involved there. Differential Revision: https://reviews.llvm.org/D50837 llvm-svn: 341358
2018-09-04 18:59:10 +08:00
; X64-NOPIC-NEXT: orq %rax, %rsp
; X64-NOPIC-NEXT: movq $.Lslh_ret_addr6, %r14
; X64-NOPIC-NEXT: callq __sigsetjmp
; X64-NOPIC-NEXT: .Lslh_ret_addr6:
; X64-NOPIC-NEXT: movq %rsp, %rcx
; X64-NOPIC-NEXT: sarq $63, %rcx
; X64-NOPIC-NEXT: cmpq $.Lslh_ret_addr6, %r14
; X64-NOPIC-NEXT: cmovneq %r15, %rcx
; X64-NOPIC-NEXT: addl (%rbx), %ebp
; X64-NOPIC-NEXT: orl %ecx, %ebp
; X64-NOPIC-NEXT: shlq $47, %rcx
; X64-NOPIC-NEXT: movl %ebp, %eax
; X64-NOPIC-NEXT: orq %rcx, %rsp
; X64-NOPIC-NEXT: addq $16, %rsp
; X64-NOPIC-NEXT: popq %rbx
; X64-NOPIC-NEXT: popq %r12
; X64-NOPIC-NEXT: popq %r14
; X64-NOPIC-NEXT: popq %r15
; X64-NOPIC-NEXT: popq %rbp
; X64-NOPIC-NEXT: retq
;
; X64-NOPIC-MCM-LABEL: test_call_setjmp:
; X64-NOPIC-MCM: # %bb.0: # %entry
; X64-NOPIC-MCM-NEXT: pushq %rbp
; X64-NOPIC-MCM-NEXT: pushq %r15
; X64-NOPIC-MCM-NEXT: pushq %r14
; X64-NOPIC-MCM-NEXT: pushq %r12
; X64-NOPIC-MCM-NEXT: pushq %rbx
; X64-NOPIC-MCM-NEXT: subq $16, %rsp
; X64-NOPIC-MCM-NEXT: movq %rsp, %rax
; X64-NOPIC-MCM-NEXT: movq %rdi, %rbx
; X64-NOPIC-MCM-NEXT: movq $-1, %r15
; X64-NOPIC-MCM-NEXT: sarq $63, %rax
; X64-NOPIC-MCM-NEXT: movq %rsp, %r14
; X64-NOPIC-MCM-NEXT: shlq $47, %rax
; X64-NOPIC-MCM-NEXT: movq %r14, %rdi
; X64-NOPIC-MCM-NEXT: orq %rax, %rsp
[SLH] Regenerate tests with --no_x86_scrub_rip to restore the higher fidelity checking of RIP-based references to basic blocks and other labels. These labels are super important for SLH tests so we should keep them readable in the test cases. llvm-svn: 348373
2018-12-05 23:41:13 +08:00
; X64-NOPIC-MCM-NEXT: leaq .Lslh_ret_addr4(%rip), %rbp
[x86/SLH] Teach SLH to harden against the "ret2spec" attack by implementing the proposed mitigation technique described in the original design document. The idea is to check after calls that the return address used to arrive at that location is in fact the correct address. In the event of a mis-predicted return which reaches a *valid* return but not the *correct* return, this will detect the mismatch much like it would a mispredicted conditional branch. This is the last published attack vector that I am aware of in the Spectre v1 space which is not mitigated by SLH+retpolines. However, don't read *too* much into that: this is an area of ongoing research where we expect more issues to be discovered in the future, and it also makes no attempt to mitigate Spectre v4. Still, this is an important completeness bar for SLH. The change here is of course delightfully simple. It was predicated on cutting support for post-instruction symbols into LLVM which was not at all simple. Many thanks to Hal Finkel, Reid Kleckner, and Justin Bogner who helped me figure out how to do a bunch of the complex changes involved there. Differential Revision: https://reviews.llvm.org/D50837 llvm-svn: 341358
2018-09-04 18:59:10 +08:00
; X64-NOPIC-MCM-NEXT: callq setjmp
; X64-NOPIC-MCM-NEXT: .Lslh_ret_addr4:
; X64-NOPIC-MCM-NEXT: movq %rsp, %rax
; X64-NOPIC-MCM-NEXT: sarq $63, %rax
[SLH] Regenerate tests with --no_x86_scrub_rip to restore the higher fidelity checking of RIP-based references to basic blocks and other labels. These labels are super important for SLH tests so we should keep them readable in the test cases. llvm-svn: 348373
2018-12-05 23:41:13 +08:00
; X64-NOPIC-MCM-NEXT: leaq .Lslh_ret_addr4(%rip), %rcx
[x86/SLH] Teach SLH to harden against the "ret2spec" attack by implementing the proposed mitigation technique described in the original design document. The idea is to check after calls that the return address used to arrive at that location is in fact the correct address. In the event of a mis-predicted return which reaches a *valid* return but not the *correct* return, this will detect the mismatch much like it would a mispredicted conditional branch. This is the last published attack vector that I am aware of in the Spectre v1 space which is not mitigated by SLH+retpolines. However, don't read *too* much into that: this is an area of ongoing research where we expect more issues to be discovered in the future, and it also makes no attempt to mitigate Spectre v4. Still, this is an important completeness bar for SLH. The change here is of course delightfully simple. It was predicated on cutting support for post-instruction symbols into LLVM which was not at all simple. Many thanks to Hal Finkel, Reid Kleckner, and Justin Bogner who helped me figure out how to do a bunch of the complex changes involved there. Differential Revision: https://reviews.llvm.org/D50837 llvm-svn: 341358
2018-09-04 18:59:10 +08:00
; X64-NOPIC-MCM-NEXT: cmpq %rcx, %rbp
; X64-NOPIC-MCM-NEXT: cmovneq %r15, %rax
; X64-NOPIC-MCM-NEXT: movl (%rbx), %ebp
; X64-NOPIC-MCM-NEXT: shlq $47, %rax
; X64-NOPIC-MCM-NEXT: movq %r14, %rdi
Bias physical register immediate assignments The machine scheduler currently biases register copies to/from physical registers to be closer to their point of use / def to minimize their live ranges. This change extends this to also physical register assignments from immediate values. This causes a reduction in reduction in overall register pressure and minor reduction in spills and indirectly fixes an out-of-registers assertion (PR39391). Most test changes are from minor instruction reorderings and register name selection changes and direct consequences of that. Reviewers: MatzeB, qcolombet, myatsina, pcc Subscribers: nemanjai, jvesely, nhaehnle, eraman, hiraditya, javed.absar, arphaman, jfb, jsji, llvm-commits Differential Revision: https://reviews.llvm.org/D54218 llvm-svn: 346894
2018-11-15 05:11:53 +08:00
; X64-NOPIC-MCM-NEXT: movl $42, %esi
[x86/SLH] Teach SLH to harden against the "ret2spec" attack by implementing the proposed mitigation technique described in the original design document. The idea is to check after calls that the return address used to arrive at that location is in fact the correct address. In the event of a mis-predicted return which reaches a *valid* return but not the *correct* return, this will detect the mismatch much like it would a mispredicted conditional branch. This is the last published attack vector that I am aware of in the Spectre v1 space which is not mitigated by SLH+retpolines. However, don't read *too* much into that: this is an area of ongoing research where we expect more issues to be discovered in the future, and it also makes no attempt to mitigate Spectre v4. Still, this is an important completeness bar for SLH. The change here is of course delightfully simple. It was predicated on cutting support for post-instruction symbols into LLVM which was not at all simple. Many thanks to Hal Finkel, Reid Kleckner, and Justin Bogner who helped me figure out how to do a bunch of the complex changes involved there. Differential Revision: https://reviews.llvm.org/D50837 llvm-svn: 341358
2018-09-04 18:59:10 +08:00
; X64-NOPIC-MCM-NEXT: orq %rax, %rsp
[SLH] Regenerate tests with --no_x86_scrub_rip to restore the higher fidelity checking of RIP-based references to basic blocks and other labels. These labels are super important for SLH tests so we should keep them readable in the test cases. llvm-svn: 348373
2018-12-05 23:41:13 +08:00
; X64-NOPIC-MCM-NEXT: leaq .Lslh_ret_addr5(%rip), %r12
[x86/SLH] Teach SLH to harden against the "ret2spec" attack by implementing the proposed mitigation technique described in the original design document. The idea is to check after calls that the return address used to arrive at that location is in fact the correct address. In the event of a mis-predicted return which reaches a *valid* return but not the *correct* return, this will detect the mismatch much like it would a mispredicted conditional branch. This is the last published attack vector that I am aware of in the Spectre v1 space which is not mitigated by SLH+retpolines. However, don't read *too* much into that: this is an area of ongoing research where we expect more issues to be discovered in the future, and it also makes no attempt to mitigate Spectre v4. Still, this is an important completeness bar for SLH. The change here is of course delightfully simple. It was predicated on cutting support for post-instruction symbols into LLVM which was not at all simple. Many thanks to Hal Finkel, Reid Kleckner, and Justin Bogner who helped me figure out how to do a bunch of the complex changes involved there. Differential Revision: https://reviews.llvm.org/D50837 llvm-svn: 341358
2018-09-04 18:59:10 +08:00
; X64-NOPIC-MCM-NEXT: callq sigsetjmp
; X64-NOPIC-MCM-NEXT: .Lslh_ret_addr5:
; X64-NOPIC-MCM-NEXT: movq %rsp, %rax
; X64-NOPIC-MCM-NEXT: sarq $63, %rax
[SLH] Regenerate tests with --no_x86_scrub_rip to restore the higher fidelity checking of RIP-based references to basic blocks and other labels. These labels are super important for SLH tests so we should keep them readable in the test cases. llvm-svn: 348373
2018-12-05 23:41:13 +08:00
; X64-NOPIC-MCM-NEXT: leaq .Lslh_ret_addr5(%rip), %rcx
[x86/SLH] Teach SLH to harden against the "ret2spec" attack by implementing the proposed mitigation technique described in the original design document. The idea is to check after calls that the return address used to arrive at that location is in fact the correct address. In the event of a mis-predicted return which reaches a *valid* return but not the *correct* return, this will detect the mismatch much like it would a mispredicted conditional branch. This is the last published attack vector that I am aware of in the Spectre v1 space which is not mitigated by SLH+retpolines. However, don't read *too* much into that: this is an area of ongoing research where we expect more issues to be discovered in the future, and it also makes no attempt to mitigate Spectre v4. Still, this is an important completeness bar for SLH. The change here is of course delightfully simple. It was predicated on cutting support for post-instruction symbols into LLVM which was not at all simple. Many thanks to Hal Finkel, Reid Kleckner, and Justin Bogner who helped me figure out how to do a bunch of the complex changes involved there. Differential Revision: https://reviews.llvm.org/D50837 llvm-svn: 341358
2018-09-04 18:59:10 +08:00
; X64-NOPIC-MCM-NEXT: cmpq %rcx, %r12
; X64-NOPIC-MCM-NEXT: cmovneq %r15, %rax
; X64-NOPIC-MCM-NEXT: addl (%rbx), %ebp
; X64-NOPIC-MCM-NEXT: shlq $47, %rax
; X64-NOPIC-MCM-NEXT: movq %r14, %rdi
; X64-NOPIC-MCM-NEXT: movq %r14, %rsi
Bias physical register immediate assignments The machine scheduler currently biases register copies to/from physical registers to be closer to their point of use / def to minimize their live ranges. This change extends this to also physical register assignments from immediate values. This causes a reduction in reduction in overall register pressure and minor reduction in spills and indirectly fixes an out-of-registers assertion (PR39391). Most test changes are from minor instruction reorderings and register name selection changes and direct consequences of that. Reviewers: MatzeB, qcolombet, myatsina, pcc Subscribers: nemanjai, jvesely, nhaehnle, eraman, hiraditya, javed.absar, arphaman, jfb, jsji, llvm-commits Differential Revision: https://reviews.llvm.org/D54218 llvm-svn: 346894
2018-11-15 05:11:53 +08:00
; X64-NOPIC-MCM-NEXT: movl $42, %edx
[x86/SLH] Teach SLH to harden against the "ret2spec" attack by implementing the proposed mitigation technique described in the original design document. The idea is to check after calls that the return address used to arrive at that location is in fact the correct address. In the event of a mis-predicted return which reaches a *valid* return but not the *correct* return, this will detect the mismatch much like it would a mispredicted conditional branch. This is the last published attack vector that I am aware of in the Spectre v1 space which is not mitigated by SLH+retpolines. However, don't read *too* much into that: this is an area of ongoing research where we expect more issues to be discovered in the future, and it also makes no attempt to mitigate Spectre v4. Still, this is an important completeness bar for SLH. The change here is of course delightfully simple. It was predicated on cutting support for post-instruction symbols into LLVM which was not at all simple. Many thanks to Hal Finkel, Reid Kleckner, and Justin Bogner who helped me figure out how to do a bunch of the complex changes involved there. Differential Revision: https://reviews.llvm.org/D50837 llvm-svn: 341358
2018-09-04 18:59:10 +08:00
; X64-NOPIC-MCM-NEXT: orq %rax, %rsp
[SLH] Regenerate tests with --no_x86_scrub_rip to restore the higher fidelity checking of RIP-based references to basic blocks and other labels. These labels are super important for SLH tests so we should keep them readable in the test cases. llvm-svn: 348373
2018-12-05 23:41:13 +08:00
; X64-NOPIC-MCM-NEXT: leaq .Lslh_ret_addr6(%rip), %r14
[x86/SLH] Teach SLH to harden against the "ret2spec" attack by implementing the proposed mitigation technique described in the original design document. The idea is to check after calls that the return address used to arrive at that location is in fact the correct address. In the event of a mis-predicted return which reaches a *valid* return but not the *correct* return, this will detect the mismatch much like it would a mispredicted conditional branch. This is the last published attack vector that I am aware of in the Spectre v1 space which is not mitigated by SLH+retpolines. However, don't read *too* much into that: this is an area of ongoing research where we expect more issues to be discovered in the future, and it also makes no attempt to mitigate Spectre v4. Still, this is an important completeness bar for SLH. The change here is of course delightfully simple. It was predicated on cutting support for post-instruction symbols into LLVM which was not at all simple. Many thanks to Hal Finkel, Reid Kleckner, and Justin Bogner who helped me figure out how to do a bunch of the complex changes involved there. Differential Revision: https://reviews.llvm.org/D50837 llvm-svn: 341358
2018-09-04 18:59:10 +08:00
; X64-NOPIC-MCM-NEXT: callq __sigsetjmp
; X64-NOPIC-MCM-NEXT: .Lslh_ret_addr6:
; X64-NOPIC-MCM-NEXT: movq %rsp, %rcx
; X64-NOPIC-MCM-NEXT: sarq $63, %rcx
[SLH] Regenerate tests with --no_x86_scrub_rip to restore the higher fidelity checking of RIP-based references to basic blocks and other labels. These labels are super important for SLH tests so we should keep them readable in the test cases. llvm-svn: 348373
2018-12-05 23:41:13 +08:00
; X64-NOPIC-MCM-NEXT: leaq .Lslh_ret_addr6(%rip), %rax
[x86/SLH] Teach SLH to harden against the "ret2spec" attack by implementing the proposed mitigation technique described in the original design document. The idea is to check after calls that the return address used to arrive at that location is in fact the correct address. In the event of a mis-predicted return which reaches a *valid* return but not the *correct* return, this will detect the mismatch much like it would a mispredicted conditional branch. This is the last published attack vector that I am aware of in the Spectre v1 space which is not mitigated by SLH+retpolines. However, don't read *too* much into that: this is an area of ongoing research where we expect more issues to be discovered in the future, and it also makes no attempt to mitigate Spectre v4. Still, this is an important completeness bar for SLH. The change here is of course delightfully simple. It was predicated on cutting support for post-instruction symbols into LLVM which was not at all simple. Many thanks to Hal Finkel, Reid Kleckner, and Justin Bogner who helped me figure out how to do a bunch of the complex changes involved there. Differential Revision: https://reviews.llvm.org/D50837 llvm-svn: 341358
2018-09-04 18:59:10 +08:00
; X64-NOPIC-MCM-NEXT: cmpq %rax, %r14
; X64-NOPIC-MCM-NEXT: cmovneq %r15, %rcx
; X64-NOPIC-MCM-NEXT: addl (%rbx), %ebp
; X64-NOPIC-MCM-NEXT: orl %ecx, %ebp
; X64-NOPIC-MCM-NEXT: shlq $47, %rcx
; X64-NOPIC-MCM-NEXT: movl %ebp, %eax
; X64-NOPIC-MCM-NEXT: orq %rcx, %rsp
; X64-NOPIC-MCM-NEXT: addq $16, %rsp
; X64-NOPIC-MCM-NEXT: popq %rbx
; X64-NOPIC-MCM-NEXT: popq %r12
; X64-NOPIC-MCM-NEXT: popq %r14
; X64-NOPIC-MCM-NEXT: popq %r15
; X64-NOPIC-MCM-NEXT: popq %rbp
; X64-NOPIC-MCM-NEXT: retq
;
; X64-PIC-LABEL: test_call_setjmp:
; X64-PIC: # %bb.0: # %entry
; X64-PIC-NEXT: pushq %rbp
; X64-PIC-NEXT: pushq %r15
; X64-PIC-NEXT: pushq %r14
; X64-PIC-NEXT: pushq %r12
; X64-PIC-NEXT: pushq %rbx
; X64-PIC-NEXT: subq $16, %rsp
; X64-PIC-NEXT: movq %rsp, %rax
; X64-PIC-NEXT: movq %rdi, %rbx
; X64-PIC-NEXT: movq $-1, %r15
; X64-PIC-NEXT: sarq $63, %rax
; X64-PIC-NEXT: movq %rsp, %r14
; X64-PIC-NEXT: shlq $47, %rax
; X64-PIC-NEXT: movq %r14, %rdi
; X64-PIC-NEXT: orq %rax, %rsp
[SLH] Regenerate tests with --no_x86_scrub_rip to restore the higher fidelity checking of RIP-based references to basic blocks and other labels. These labels are super important for SLH tests so we should keep them readable in the test cases. llvm-svn: 348373
2018-12-05 23:41:13 +08:00
; X64-PIC-NEXT: leaq .Lslh_ret_addr4(%rip), %rbp
[x86/SLH] Teach SLH to harden against the "ret2spec" attack by implementing the proposed mitigation technique described in the original design document. The idea is to check after calls that the return address used to arrive at that location is in fact the correct address. In the event of a mis-predicted return which reaches a *valid* return but not the *correct* return, this will detect the mismatch much like it would a mispredicted conditional branch. This is the last published attack vector that I am aware of in the Spectre v1 space which is not mitigated by SLH+retpolines. However, don't read *too* much into that: this is an area of ongoing research where we expect more issues to be discovered in the future, and it also makes no attempt to mitigate Spectre v4. Still, this is an important completeness bar for SLH. The change here is of course delightfully simple. It was predicated on cutting support for post-instruction symbols into LLVM which was not at all simple. Many thanks to Hal Finkel, Reid Kleckner, and Justin Bogner who helped me figure out how to do a bunch of the complex changes involved there. Differential Revision: https://reviews.llvm.org/D50837 llvm-svn: 341358
2018-09-04 18:59:10 +08:00
; X64-PIC-NEXT: callq setjmp@PLT
; X64-PIC-NEXT: .Lslh_ret_addr4:
; X64-PIC-NEXT: movq %rsp, %rax
; X64-PIC-NEXT: sarq $63, %rax
[SLH] Regenerate tests with --no_x86_scrub_rip to restore the higher fidelity checking of RIP-based references to basic blocks and other labels. These labels are super important for SLH tests so we should keep them readable in the test cases. llvm-svn: 348373
2018-12-05 23:41:13 +08:00
; X64-PIC-NEXT: leaq .Lslh_ret_addr4(%rip), %rcx
[x86/SLH] Teach SLH to harden against the "ret2spec" attack by implementing the proposed mitigation technique described in the original design document. The idea is to check after calls that the return address used to arrive at that location is in fact the correct address. In the event of a mis-predicted return which reaches a *valid* return but not the *correct* return, this will detect the mismatch much like it would a mispredicted conditional branch. This is the last published attack vector that I am aware of in the Spectre v1 space which is not mitigated by SLH+retpolines. However, don't read *too* much into that: this is an area of ongoing research where we expect more issues to be discovered in the future, and it also makes no attempt to mitigate Spectre v4. Still, this is an important completeness bar for SLH. The change here is of course delightfully simple. It was predicated on cutting support for post-instruction symbols into LLVM which was not at all simple. Many thanks to Hal Finkel, Reid Kleckner, and Justin Bogner who helped me figure out how to do a bunch of the complex changes involved there. Differential Revision: https://reviews.llvm.org/D50837 llvm-svn: 341358
2018-09-04 18:59:10 +08:00
; X64-PIC-NEXT: cmpq %rcx, %rbp
; X64-PIC-NEXT: cmovneq %r15, %rax
; X64-PIC-NEXT: movl (%rbx), %ebp
; X64-PIC-NEXT: shlq $47, %rax
; X64-PIC-NEXT: movq %r14, %rdi
Bias physical register immediate assignments The machine scheduler currently biases register copies to/from physical registers to be closer to their point of use / def to minimize their live ranges. This change extends this to also physical register assignments from immediate values. This causes a reduction in reduction in overall register pressure and minor reduction in spills and indirectly fixes an out-of-registers assertion (PR39391). Most test changes are from minor instruction reorderings and register name selection changes and direct consequences of that. Reviewers: MatzeB, qcolombet, myatsina, pcc Subscribers: nemanjai, jvesely, nhaehnle, eraman, hiraditya, javed.absar, arphaman, jfb, jsji, llvm-commits Differential Revision: https://reviews.llvm.org/D54218 llvm-svn: 346894
2018-11-15 05:11:53 +08:00
; X64-PIC-NEXT: movl $42, %esi
[x86/SLH] Teach SLH to harden against the "ret2spec" attack by implementing the proposed mitigation technique described in the original design document. The idea is to check after calls that the return address used to arrive at that location is in fact the correct address. In the event of a mis-predicted return which reaches a *valid* return but not the *correct* return, this will detect the mismatch much like it would a mispredicted conditional branch. This is the last published attack vector that I am aware of in the Spectre v1 space which is not mitigated by SLH+retpolines. However, don't read *too* much into that: this is an area of ongoing research where we expect more issues to be discovered in the future, and it also makes no attempt to mitigate Spectre v4. Still, this is an important completeness bar for SLH. The change here is of course delightfully simple. It was predicated on cutting support for post-instruction symbols into LLVM which was not at all simple. Many thanks to Hal Finkel, Reid Kleckner, and Justin Bogner who helped me figure out how to do a bunch of the complex changes involved there. Differential Revision: https://reviews.llvm.org/D50837 llvm-svn: 341358
2018-09-04 18:59:10 +08:00
; X64-PIC-NEXT: orq %rax, %rsp
[SLH] Regenerate tests with --no_x86_scrub_rip to restore the higher fidelity checking of RIP-based references to basic blocks and other labels. These labels are super important for SLH tests so we should keep them readable in the test cases. llvm-svn: 348373
2018-12-05 23:41:13 +08:00
; X64-PIC-NEXT: leaq .Lslh_ret_addr5(%rip), %r12
[x86/SLH] Teach SLH to harden against the "ret2spec" attack by implementing the proposed mitigation technique described in the original design document. The idea is to check after calls that the return address used to arrive at that location is in fact the correct address. In the event of a mis-predicted return which reaches a *valid* return but not the *correct* return, this will detect the mismatch much like it would a mispredicted conditional branch. This is the last published attack vector that I am aware of in the Spectre v1 space which is not mitigated by SLH+retpolines. However, don't read *too* much into that: this is an area of ongoing research where we expect more issues to be discovered in the future, and it also makes no attempt to mitigate Spectre v4. Still, this is an important completeness bar for SLH. The change here is of course delightfully simple. It was predicated on cutting support for post-instruction symbols into LLVM which was not at all simple. Many thanks to Hal Finkel, Reid Kleckner, and Justin Bogner who helped me figure out how to do a bunch of the complex changes involved there. Differential Revision: https://reviews.llvm.org/D50837 llvm-svn: 341358
2018-09-04 18:59:10 +08:00
; X64-PIC-NEXT: callq sigsetjmp@PLT
; X64-PIC-NEXT: .Lslh_ret_addr5:
; X64-PIC-NEXT: movq %rsp, %rax
; X64-PIC-NEXT: sarq $63, %rax
[SLH] Regenerate tests with --no_x86_scrub_rip to restore the higher fidelity checking of RIP-based references to basic blocks and other labels. These labels are super important for SLH tests so we should keep them readable in the test cases. llvm-svn: 348373
2018-12-05 23:41:13 +08:00
; X64-PIC-NEXT: leaq .Lslh_ret_addr5(%rip), %rcx
[x86/SLH] Teach SLH to harden against the "ret2spec" attack by implementing the proposed mitigation technique described in the original design document. The idea is to check after calls that the return address used to arrive at that location is in fact the correct address. In the event of a mis-predicted return which reaches a *valid* return but not the *correct* return, this will detect the mismatch much like it would a mispredicted conditional branch. This is the last published attack vector that I am aware of in the Spectre v1 space which is not mitigated by SLH+retpolines. However, don't read *too* much into that: this is an area of ongoing research where we expect more issues to be discovered in the future, and it also makes no attempt to mitigate Spectre v4. Still, this is an important completeness bar for SLH. The change here is of course delightfully simple. It was predicated on cutting support for post-instruction symbols into LLVM which was not at all simple. Many thanks to Hal Finkel, Reid Kleckner, and Justin Bogner who helped me figure out how to do a bunch of the complex changes involved there. Differential Revision: https://reviews.llvm.org/D50837 llvm-svn: 341358
2018-09-04 18:59:10 +08:00
; X64-PIC-NEXT: cmpq %rcx, %r12
; X64-PIC-NEXT: cmovneq %r15, %rax
; X64-PIC-NEXT: addl (%rbx), %ebp
; X64-PIC-NEXT: shlq $47, %rax
; X64-PIC-NEXT: movq %r14, %rdi
; X64-PIC-NEXT: movq %r14, %rsi
Bias physical register immediate assignments The machine scheduler currently biases register copies to/from physical registers to be closer to their point of use / def to minimize their live ranges. This change extends this to also physical register assignments from immediate values. This causes a reduction in reduction in overall register pressure and minor reduction in spills and indirectly fixes an out-of-registers assertion (PR39391). Most test changes are from minor instruction reorderings and register name selection changes and direct consequences of that. Reviewers: MatzeB, qcolombet, myatsina, pcc Subscribers: nemanjai, jvesely, nhaehnle, eraman, hiraditya, javed.absar, arphaman, jfb, jsji, llvm-commits Differential Revision: https://reviews.llvm.org/D54218 llvm-svn: 346894
2018-11-15 05:11:53 +08:00
; X64-PIC-NEXT: movl $42, %edx
[x86/SLH] Teach SLH to harden against the "ret2spec" attack by implementing the proposed mitigation technique described in the original design document. The idea is to check after calls that the return address used to arrive at that location is in fact the correct address. In the event of a mis-predicted return which reaches a *valid* return but not the *correct* return, this will detect the mismatch much like it would a mispredicted conditional branch. This is the last published attack vector that I am aware of in the Spectre v1 space which is not mitigated by SLH+retpolines. However, don't read *too* much into that: this is an area of ongoing research where we expect more issues to be discovered in the future, and it also makes no attempt to mitigate Spectre v4. Still, this is an important completeness bar for SLH. The change here is of course delightfully simple. It was predicated on cutting support for post-instruction symbols into LLVM which was not at all simple. Many thanks to Hal Finkel, Reid Kleckner, and Justin Bogner who helped me figure out how to do a bunch of the complex changes involved there. Differential Revision: https://reviews.llvm.org/D50837 llvm-svn: 341358
2018-09-04 18:59:10 +08:00
; X64-PIC-NEXT: orq %rax, %rsp
[SLH] Regenerate tests with --no_x86_scrub_rip to restore the higher fidelity checking of RIP-based references to basic blocks and other labels. These labels are super important for SLH tests so we should keep them readable in the test cases. llvm-svn: 348373
2018-12-05 23:41:13 +08:00
; X64-PIC-NEXT: leaq .Lslh_ret_addr6(%rip), %r14
[x86/SLH] Teach SLH to harden against the "ret2spec" attack by implementing the proposed mitigation technique described in the original design document. The idea is to check after calls that the return address used to arrive at that location is in fact the correct address. In the event of a mis-predicted return which reaches a *valid* return but not the *correct* return, this will detect the mismatch much like it would a mispredicted conditional branch. This is the last published attack vector that I am aware of in the Spectre v1 space which is not mitigated by SLH+retpolines. However, don't read *too* much into that: this is an area of ongoing research where we expect more issues to be discovered in the future, and it also makes no attempt to mitigate Spectre v4. Still, this is an important completeness bar for SLH. The change here is of course delightfully simple. It was predicated on cutting support for post-instruction symbols into LLVM which was not at all simple. Many thanks to Hal Finkel, Reid Kleckner, and Justin Bogner who helped me figure out how to do a bunch of the complex changes involved there. Differential Revision: https://reviews.llvm.org/D50837 llvm-svn: 341358
2018-09-04 18:59:10 +08:00
; X64-PIC-NEXT: callq __sigsetjmp@PLT
; X64-PIC-NEXT: .Lslh_ret_addr6:
; X64-PIC-NEXT: movq %rsp, %rcx
; X64-PIC-NEXT: sarq $63, %rcx
[SLH] Regenerate tests with --no_x86_scrub_rip to restore the higher fidelity checking of RIP-based references to basic blocks and other labels. These labels are super important for SLH tests so we should keep them readable in the test cases. llvm-svn: 348373
2018-12-05 23:41:13 +08:00
; X64-PIC-NEXT: leaq .Lslh_ret_addr6(%rip), %rax
[x86/SLH] Teach SLH to harden against the "ret2spec" attack by implementing the proposed mitigation technique described in the original design document. The idea is to check after calls that the return address used to arrive at that location is in fact the correct address. In the event of a mis-predicted return which reaches a *valid* return but not the *correct* return, this will detect the mismatch much like it would a mispredicted conditional branch. This is the last published attack vector that I am aware of in the Spectre v1 space which is not mitigated by SLH+retpolines. However, don't read *too* much into that: this is an area of ongoing research where we expect more issues to be discovered in the future, and it also makes no attempt to mitigate Spectre v4. Still, this is an important completeness bar for SLH. The change here is of course delightfully simple. It was predicated on cutting support for post-instruction symbols into LLVM which was not at all simple. Many thanks to Hal Finkel, Reid Kleckner, and Justin Bogner who helped me figure out how to do a bunch of the complex changes involved there. Differential Revision: https://reviews.llvm.org/D50837 llvm-svn: 341358
2018-09-04 18:59:10 +08:00
; X64-PIC-NEXT: cmpq %rax, %r14
; X64-PIC-NEXT: cmovneq %r15, %rcx
; X64-PIC-NEXT: addl (%rbx), %ebp
; X64-PIC-NEXT: orl %ecx, %ebp
; X64-PIC-NEXT: shlq $47, %rcx
; X64-PIC-NEXT: movl %ebp, %eax
; X64-PIC-NEXT: orq %rcx, %rsp
; X64-PIC-NEXT: addq $16, %rsp
; X64-PIC-NEXT: popq %rbx
; X64-PIC-NEXT: popq %r12
; X64-PIC-NEXT: popq %r14
; X64-PIC-NEXT: popq %r15
; X64-PIC-NEXT: popq %rbp
; X64-PIC-NEXT: retq
entry:
%env = alloca i8, i32 16
; Call a normal setjmp function.
call i32 @setjmp(i8* %env)
%x = load i32, i32* %ptr
; Call something like sigsetjmp.
call i32 @sigsetjmp(i8* %env, i32 42)
%y = load i32, i32* %ptr
; Call something that might be an implementation detail expanded out of a
; macro that has a weird signature but still gets annotated as returning
; twice.
call i32 @__sigsetjmp(i8* %env, i8* %env, i32 42)
%z = load i32, i32* %ptr
%s1 = add i32 %x, %y
%s2 = add i32 %s1, %z
ret i32 %s2
}