linux-hardening - Re: [PATCH] [RFC][PR102768] aarch64: Add compiler support for Shadow Call Stack

lists.openwall.net		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 21:39:08 +0800
From:   Dan Li <ashimida@...ux.alibaba.com>
To:     Szabolcs Nagy <szabolcs.nagy@....com>
Cc:     gcc-patches@....gnu.org, linux-hardening@...r.kernel.org
Subject: Re: [PATCH] [RFC][PR102768] aarch64: Add compiler support for Shadow
 Call Stack



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
>>