lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Tue, 23 Nov 2021 10:51:49 +0000
From:   Szabolcs Nagy <>
To:     Dan Li <>
Subject: Re: [PATCH] [RFC][PR102768] aarch64: Add compiler support for Shadow
 Call Stack

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]
> [2]
> [3]

Powered by blists - more mailing lists