About
Shadow stacks are a security feature meant to detect/prevent classes of attacks where a malicious actor has gained control over a function's return pointer. Shadow stack mechanisms typically need a combination of compiler, library, dynamic loader and kernel support, they often require special support for JITs as well. This work item is only tracking the core LLVM functionality needed to support shadow stacks. Shadow stacks are seen as a blocking issue for Android on RISC-V.
Stakeholders/Partners
RISE:
Ventana: Coordination with GCC community
Google: FTE driving implementation work
Mediatek: FTE driving implementation work
External:
Alex Bradbury:
Dependencies
The most pressing upstream dependencies are:
- PSABI specification to allow turning x3 into an OS defined register (rather than forcing it to be a global data pointer)
- Kernel and library support to enable shadow stack feature, library support to facilitate routines such as longjmp or unwinding which inherently need to pop values off the shadow stack
- Linker and dynamic loader support to either prevent mixing and matching of shadow stack aware code with non-aware code, or thunks between the domains to turn shadow stacks on/off.
- QEMU and/or Spike support for Zicfisslp
Status
Updates
- The investigation on the 6 run failures is done. It turns out they are not Oz-specific failures, i.e. these 6 test cases failed for all optimization levels but our error reporting mechanism didn't catch the failures because we only checked the "passed" output string but didn't check shadow stack fault. We've fixed the error reporting system.
The root cause of the shadow stack fault on the 6 test cases is due to a lack of setjmp/longjmp support to save and restore shadow stack pointer. - We will study glibc and try to add the support. We will also add Zicfiss instructions that are required by setjmp/longjmp into Spike for validation purpose, such as ssrdp, ssld, etc.
An example glibc patch for x86 shadow stack can be found here: https://github.com/bminor/glibc/commit/faaee1f07ed25b2779bfd935ffb29f431b80d6d3
ABI discussions on jmp_buf can be found here: https://github.com/riscv/riscv-cfi/issues/142
- Two essential LLVM patches that implement Zicfiss v0.2 have been posted for review by fakepaper56 (thumbs up). We have validated these patches using Spike with newly added Zicfiss v0.3.1 instructions. It only requires slight encoding adjustment to run the validation. The validation results look good. There are only 6 run fails with -Oz for total 80K test programs. We will investigate these run fails.
https://reviews.llvm.org/D152793
https://reviews.llvm.org/D156549
- Built up a compiler validation environment based on Spike, on which we can run 13K C/C++ test cases with various optimization levels (O0, O1, O2, O3, Os, and Oz). The combinations (13K test cases x 6 optimization levels) will be sufficient for validating LLVM Zicfiss implementation.
- Successfully added sspush and sspopchk instruction into Spike. Although there are more instructions to be added (ssload, sspinc, etc), the current implementation already enables us to run most of the compiler tests with Zicfiss enabled. The next step will be building up a test environment for running commercial testsuites on Spike to obtain the original pass rate without Zicfiss enabled.
- Discussing a Zicfiss support proposal with Google. Will probably implement the Zicfiss extension in Spike as well to facilitate compiler validation and avoid the dependencies on QEMU, Linux kernel, and dynamic loaders.
- Update the current status, dependencies, and work that needs to be done for Zicfisslp shadow stacks. Please refer to the following spreadsheet for details. Since this is based on my recent study, if there is anything missing or incorrect, please kindly let me know. I (Chibang) will reach out to Google and Rivos to discuss opportunities for collaboration.
https://docs.google.com/spreadsheets/d/e/2PACX-1vSMW-7hBC6omqsZDLqxU4mCiZF313IEMoNRktrgE0QErfJjKaVfDOTOLlGZThpiEK2YCKIhTpBfF4y9/pubhtml?gid=0&single=true
- Consensus forming that x3 can be repurposed as an OS specific register
– Dates on or before June 1 are approximate
- Project reported as priority for 2H23