================ @@ -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`` ---------------- samitolvanen wrote:
> Should Android default to shadow stack? > > My concern is that if a user passes an -mcpu that supports Zicfiss, but the > OS doesn't, the compiler will emit shadow stack instructions that silently > fall back to NOPs due to the missing OS support. This leaves your binary in a > state where it gets no protection. I agree, changing `-fsanitize=shadow-call-stack` behavior based on `-mcpu` is problematic, especially when it can result in the program silently falling back to unprotected state. This might be a problem for other platforms too, not only Android. 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
