9 Commits

Author SHA1 Message Date
Jesse Huang
3ad6403577
[Clang][RISCV] Remove forced-sw-shadow-stack (#115355)
This option was used to override the behavior of
`-fsanitize=shadowcallstack` on RISC-V backend, which by default use a
hardware implementation if possible, to use the software implementation
instead. After #112477 and #112478, now two implementation
is represented by independent options and we no longer need it.
2024-11-08 13:46:27 +08:00
Yeting Kuo
59037c0975
[RISCV] Add Zicfiss support to the shadow call stack implementation. (#68075)
This patch enable hardware shadow stack with `Zicifss` and
`mno-forced-sw-shadow-stack`. New feature forced-sw-shadow-stack
disables hardware shadow stack even when `Zicfiss` enabled.
2024-02-10 22:18:46 +08:00
Craig Topper
e6f576b0c3
[Docs] Mention RISC-V in the introductory paragraph in ShadowCallStack.rst. (#79241)
RISC-V is mentioned elsewhere in the document it seems like it should be
mentioned in the introduction.
2024-01-24 12:06:58 -08:00
Paul Kirth
aa1d2693c2 [CodeGen][RISCV] Change Shadow Call Stack Register to X3
ShadowCallStack implementation uses s2 register on RISC-V, but that
choice is problematic for reasons described in:

https://lists.riscv.org/g/sig-toolchains/message/544,
https://github.com/riscv-non-isa/riscv-elf-psabi-doc/issues/370, and
https://github.com/google/android-riscv64/issues/72

The concern over the register choice was also brought up in
https://reviews.llvm.org/D84414.

https://reviews.llvm.org/D84414#2228666 said:

```
  "If the register choice is the only concern about this work, then I think
  we can probably land it as-is and fixup the register choice if we see
  major drawbacks later. Yes, it's an ABI issue, but on the other hand the
  shadow call stack is not a standard ABI anyway.""
```

Since we have now found a sufficient reason to fixup the register
choice, we should go ahead and update the implementation. We propose
using x3(gp) which is now the platform register in the RISC-V ABI.

Reviewed By: asb, hiraditya, mcgrathr, craig.topper

Differential Revision: https://reviews.llvm.org/D146463
2023-04-12 21:06:22 +00:00
Vlad Tsyrklevich
2e1479e2f2 Delete x86_64 ShadowCallStack support
Summary:
ShadowCallStack on x86_64 suffered from the same racy security issues as
Return Flow Guard and had performance overhead as high as 13% depending
on the benchmark. x86_64 ShadowCallStack was always an experimental
feature and never shipped a runtime required to support it, as such
there are no expected downstream users.

Reviewers: pcc

Reviewed By: pcc

Subscribers: mgorny, javed.absar, hiraditya, jdoerfert, cfe-commits, #sanitizers, llvm-commits

Tags: #clang, #sanitizers, #llvm

Differential Revision: https://reviews.llvm.org/D59034

llvm-svn: 355624
2019-03-07 18:56:36 +00:00
Peter Collingbourne
27aa8b62d3 docs: Update the ShadowCallStack documentation.
- Remove most of the discussion of the x86_64 implementation;
  link to an older version of the documentation for details of
  that implementation.
- Add description of the compatibility and security issues discovered
  during the development of the aarch64 implementation for Android.

Differential Revision: https://reviews.llvm.org/D58105

llvm-svn: 353890
2019-02-12 22:45:23 +00:00
Kostya Serebryany
d5dc819a5c [ShadowCallStack] fix the docs
llvm-svn: 331238
2018-05-01 00:15:56 +00:00
Peter Collingbourne
f11eb3ebe7 AArch64: Implement support for the shadowcallstack attribute.
The implementation of shadow call stack on aarch64 is quite different to
the implementation on x86_64. Instead of reserving a segment register for
the shadow call stack, we reserve the platform register, x18. Any function
that spills lr to sp also spills it to the shadow call stack, a pointer to
which is stored in x18.

Differential Revision: https://reviews.llvm.org/D45239

llvm-svn: 329236
2018-04-04 21:55:44 +00:00
Vlad Tsyrklevich
e55aa03ad4 Add the -fsanitize=shadow-call-stack flag
Summary:
Add support for the -fsanitize=shadow-call-stack flag which causes clang
to add ShadowCallStack attribute to functions compiled with that flag
enabled.

Reviewers: pcc, kcc

Reviewed By: pcc, kcc

Subscribers: cryptoad, cfe-commits, kcc

Differential Revision: https://reviews.llvm.org/D44801

llvm-svn: 329122
2018-04-03 22:33:53 +00:00