https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102768
--- Comment #2 from ashimida <ashimida at linux dot alibaba.com> --- (In reply to nsz from comment #1) > note that this at least > > - requires runtime support (to manage the shadow stack), > - needs a reserved register (x18), > - affects unwinding (shadow stack must be unwound too), > - affects longjmp and jmp_buf abi. > > i guess these are taken care of in the linux context and in > that case i think it makes sense to have the gcc support > upstream instead of in a plugin. > > however the general support in user-space is not trivial > (the required libc changes may not be possible in a backward > compatible way such as changing jmp_buf, or reliably such as > allocating the size of shadow stack and dealing with related > failures, or with good ui e.g. opt-in mechanism for binaries > that require shadow stack so there is no regression for > non-shadow-stack binaries, etc.) and there are existing stack > protection mechanisms implemented. > > i just wanted to note here that the linux kernel use-case > can be treated separately from user-space applications and > likely less effort and less controversial if you scope the > feature right. Thanks nsz, As far as I know, existing security mechanisms such as stack canary usually do not achieve the same effect, and pac is not always supported by hardware. As you said, it will take a lot of trivial work to let the user space support Shadow Call Stack, and Linux Kernel is ready for this. But Shadow Call Stack should be a general mechanism, just as Android can support Clang SCS by modifying bionic, gcc's basic support for SCS can provide a lot of convenience for users itself to implement user-mode SCS (users may not always need to face all the above issues) So what I want to say in the request is whether we can provide SCS support in the compiler side as a good start. Maybe it‘s better to modify the feature description as follows? [feature request] Add compiler support for aarch64 shadow call stack
