On 11/23/21 6:51 PM, Szabolcs Nagy wrote:
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).
Thanks Szabolcs,
This sounds reasonable to me, and I'll fix it in the next version.
i assume the linux kernel does not require -fexceptions.
AFAIK, -fexceptions are not used in the linux kernel.
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
