================
@@ -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
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Reply via email to