[clang] [llvm] [RISCV] Add Zicfiss support to the shadow call stack implementation. (PR #68075)

Paul Kirth via cfe-commits cfe-commits at lists.llvm.org
Tue Jan 23 10:54:45 PST 2024


================
@@ -57,11 +57,16 @@ compiled application or the operating system. Integrating the runtime into
 the operating system should be preferred since otherwise all thread creation
 and destruction would need to be intercepted by the application.
 
-The instrumentation makes use of the platform register ``x18`` on AArch64 and
-``x3`` (``gp``) on RISC-V. For simplicity we will refer to this as the
-``SCSReg``. On some platforms, ``SCSReg`` is reserved, and on others, it is
-designated as a scratch register.  This generally means that any code that may
-run on the same thread as code compiled with ShadowCallStack must either target
+The instrumentation makes use of the platform register ``x18`` on AArch64,
+``x3`` (``gp``) on RISC-V with software shadow stack and ``ssp`` on RISC-V with
+hardware shadow stack, which needs `Zicfiss`_ and ``-mno-forced-sw-shadow-stack``
----------------
ilovepi wrote:

I guess I'm in the minority here in thinking that the compiler should pick based on the HW capabilities.  I think I'd be surprised if I was compiling w/ SCS on HW that supported it and got the software SCS... but at the end of the day, as long as we document the usage clearly its probably fine. I acknowledge the concern about falling back to a less secure method, but it still feels like the wrong tradeoff to me. That said, if there's a consensus that the other way makes more sense(which there seems to be), then I'm 100% fine with that. 

Related: what are our thoughts about a frontend warning/diagnostic when the mcpu supports the feature, but hasn't been selected?

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


More information about the cfe-commits mailing list