[clang] [RISCV] Implement shadow stack on shadow stack mode with Zicfiss. (PR #68075)

Sami Tolvanen via cfe-commits cfe-commits at lists.llvm.org
Tue Oct 17 11:40:06 PDT 2023


================
@@ -106,9 +111,14 @@ static void emitSCSEpilogue(MachineFunction &MF, MachineBasicBlock &MBB,
           CSI, [&](CalleeSavedInfo &CSR) { return CSR.getReg() == RAReg; }))
     return;
 
+  const RISCVInstrInfo *TII = STI.getInstrInfo();
+  if (STI.hasFeature(RISCV::FeatureStdExtZicfiss)) {
----------------
samitolvanen wrote:

> Today, if you use software SCS on a platform without support they just fail, since the SCS won't be setup and gp(probably) points to invalid memory. Is it unreasonable to have it work the same in this case?

Sounds reasonable to me, but having a flag that allows one to explicitly select between software and hardware shadow stacks is still a good idea IMO.

> WDYT about phrasing this an an opt-out flag, like `-force-software-scs`, and using a helper function, like :

For sanitizers, extra flags have typically been something like `-fsanitize-[sanitizer]-[flag]`, e.g. `-fsanitize-cfi-icall-generalize-pointers`:

https://clang.llvm.org/docs/ControlFlowIntegrity.html#indirect-function-call-checking

> It also occurs to me that X86 is getting/has backward edge CFI, right? how do we enable that in the x86 backend? How is GCC planning to spell these options, since I would suppose there needs to be some level of compatibility.

X86 uses the `-fcf-protection` flag for backward-edge at least, and AArch64 uses `-mbranch-protection` for both backward-edge (PAC) and forward-edge (BTI). It would be great not to invent another command line option specifically for RISC-V, so I quite like the idea of reusing the existing ShadowCallStack front-end for hardware shadow stacks too.

https://github.com/llvm/llvm-project/pull/68075


More information about the cfe-commits mailing list