The 11/23/2021 16:32, Dan Li wrote: > On 11/3/21 8:00 PM, Szabolcs Nagy wrote: > > 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. > > > I recompiled a glibc and gcc runtime library with -ffixed-x18 enabled. > As you said, the scs stack needs to be popped at the same time during > exception handling. > > I saw that Clang is processed by adding > ".cfi_escape 0x16, 0x12, 0x02, 0x82, 0x78" > directive (x18 -= 8;) after each emit of scs push[2]. > > But this directive has problems when executed in libgcc: > 1)context->reg[x] in uw_init_context_1 are all based on cfa, most > registers have no initial values by default. > 2)Address of shadow call stack (x18) cannot(and should not) be calculated > based on cfa, and I did not yet find a way to assign hardware register > x18 to context->reg[18]. > 3)This causes libgcc to crash when parsing .cfi_escape exp because of 0 > address dereference (* x18) > (execute_stack_op => case DW_OP_breg18: _Unwind_GetGR) > 4)uw_install_context_1 does not restore all hardware registers by default > before eh return, so context->reg[18] can't write directly to hw x18. > (In clang, __unw_getcontext/__unw_resume will save/restore all hardware > registers, so this directive works fine in my libunwind test.) > > I tried to fix this problem through a patch[3], the exception handling > works fine in my test environment, but I'm not sure if this fix is > ppropriate for two reasons: > 1)libgcc does not push/pop all registers by default during exception > handling. Is this change appropriate? > 2)The test case may not be able to test this patch, because the test > environment requires at least on glibc/gcc runtime compiled with > -ffixed-x18. > > May be it's better to rely on -fno-exceptions for this patch first? and If > the glibc/gcc runtime also supports SCS later, the problem can be fixed > at the same time.
i did not look at the exception handling in detail (that's difficult to understand for me too). to use scs, non-default abi is required anyway, so not supporting exceptions sounds fine to me. however it should be documented and ideally enforced (-fexceptions should be rejected, just like -fno-fixed-x18). i assume the linux kernel does not require -fexceptions. > > PS: > I'm still not familiar enough with exception handling in libgcc/libunwind, > please correct me if there are any mistakes :) > > [1] > https://github.com/llvm/llvm-project/commit/f11eb3ebe77729426e562d7d4d7ebb1d5ff2e7c8 > [2] https://reviews.llvm.org/D54609 > [3] https://gcc.gnu.org/bugzilla/attachment.cgi?id=51854&action=diff >
