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

Paul Kirth via cfe-commits cfe-commits at lists.llvm.org
Fri Jan 5 16:17:03 PST 2024


================
@@ -57,11 +57,14 @@ 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``
+(default option). ``-mforced-sw-shadow-stack`` make risc-v backend generate
+software shadow stack with `Zicfiss`_ when shadow stack enabled.
----------------
ilovepi wrote:

```suggestion
hardware shadow stack, which needs `Zicfiss`_. Note that with ``Zicfiss``_ the RISC-V backend will default to the hardware based shadow call stack. Users can force the RISC-V backend to generate the software shadow call stack with ``Zicfiss``_ by passing ``-mforced-sw-shadow-stack``. 
```
Maybe this is easier to follow? Might also make sense to outline when `-mforced-sw-shadow-stack` is expected to work somewhere, e.g., it has no effect w/o `Zicfiss``.  TBH, in that case, the driver should probably issue an error, since its incompatible w/o the feature, but I'm not sure if we can do that check in the frontend or not.

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


More information about the cfe-commits mailing list