Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 23 Next »

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:

  1. PSABI specification to allow turning x3 into an OS defined register (rather than forcing it to be a global data pointer)
  2. 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
  3. 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.
  4. QEMU and/or Spike support for Zicfisslp


Status

Development

ONGOING


Development TimelineNA
Upstreaming

NOT STARTED


Upstream Version



Contacts

Nathan Egge (Google)

Chibang Kuan (Mediatek)





Dependencies

PSABI (x3 as os register)

kernel/library support

linker and dynamic loader



Updates

  • A Spike PR, which implements a Zicfiss v0.3.1 instruction subset, was posted for review by Su-Hsien (MediaTek).
    The purpose of the PR is to enable compiler validation and collect feedback. PR: https://github.com/riscv-software-src/riscv-isa-sim/pull/1475
  • We have implemented setjmp/longjmp in glibc for Zicfiss. Validation is ongoing. It may require refactoring for upstreaming.

  • 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.

 

 

  • 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


  • No labels