The 11/03/2021 00:24, Dan Li wrote: > On 11/2/21 9:04 PM, Szabolcs Nagy wrote: > > The 11/02/2021 00:06, Dan Li via Gcc-patches wrote: > > > Shadow Call Stack can be used to protect the return address of a > > > function at runtime, and clang already supports this feature[1]. > > > > > > To enable SCS in user mode, in addition to compiler, other support > > > is also required (as described in [2]). This patch only adds basic > > > support for SCS from the compiler side, and provides convenience > > > for users to enable SCS. > > > > > > For linux kernel, only the support of the compiler is required. > > > > > > [1] https://clang.llvm.org/docs/ShadowCallStack.html > > > [2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102768 > > > > i'm not a gcc maintainer, but i prefer such feature > > to be in upstream gcc instead of in a plugin. > > > > it will require update to the documentation: > > > > which should mention that it depends on -ffixed-x18 > > (probably that should be enforced too) which is an > > important abi issue: functions following the normal > > pcs can clobber x18 and break scs. > > > Thanks Szabolcs, I will update the documentation in next version. > > It sounds reasonable to enforced -ffixed-x18 with scs, but I see > that clang doesn’t do that. Maybe it is better to be consistent > with clang here?
i mean gcc can issue a diagnostic if -ffixed-x18 is not passed. (it seems clang rejects scs too without -ffixed-x18) > > and that there is no unwinder support. > > > Ok, let me try to add a support for this. i assume exception handling info has to change for scs to work (to pop the shadow stack when transferring control), so either scs must require -fno-exceptions or the eh info changes must be implemented. i think the kernel does not require exceptions and does not depend on the unwinder runtime in libgcc, so this is optional for the linux kernel use-case.
