From: Szabolcs Nagy <szabolcs.nagy@arm.com>
To: Dan Li <ashimida@linux.alibaba.com>
Cc: gcc-patches@gcc.gnu.org, linux-hardening@vger.kernel.org
Subject: Re: [PATCH] [RFC][PR102768] aarch64: Add compiler support for Shadow Call Stack
Date: Tue, 23 Nov 2021 10:51:49 +0000 [thread overview]
Message-ID: <20211123105149.GM1982710@arm.com> (raw)
In-Reply-To: <7937172c-3b1a-ffca-59c5-d75b73e5e3a7@linux.alibaba.com>
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
>
next prev parent reply other threads:[~2021-11-23 10:52 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-02 7:06 [PATCH] [RFC][PR102768] aarch64: Add compiler support for Shadow Call Stack Dan Li
2021-11-02 13:04 ` Szabolcs Nagy
2021-11-02 16:24 ` Dan Li
2021-11-03 12:00 ` Szabolcs Nagy
2021-11-23 8:32 ` Dan Li
2021-11-23 10:51 ` Szabolcs Nagy [this message]
2021-11-23 13:39 ` Dan Li
2021-12-06 2:41 ` [PATCH] [PATCH,v2,1/1,AARCH64][PR102768] " Dan Li
2021-12-06 3:22 ` Dan Li
2022-01-04 14:40 ` [PING^2][PATCH,v2,1/1,AARCH64][PR102768] " Dan Li
[not found] ` <81d54b71-7c9c-47ef-ac8d-72aae46cd4ee@linux.alibaba.com>
[not found] ` <mptk0euk42w.fsf@arm.com>
[not found] ` <a9daf6bf-94f2-0c5f-b9aa-7fb69781c9d5@linux.alibaba.com>
[not found] ` <mpto840kti9.fsf@arm.com>
[not found] ` <3ae4a533-352b-f3e3-27b3-9386df5f56c3@linux.alibaba.com>
2022-01-26 7:53 ` [PING^3][PATCH,v2,1/1,AARCH64][PR102768] " Dan Li
2022-01-26 8:10 ` Ard Biesheuvel
2022-01-26 10:35 ` Dan Li
2022-01-26 11:09 ` Ard Biesheuvel
2022-01-26 14:08 ` Dan Li
2022-01-31 16:26 ` Richard Sandiford
2022-02-02 9:25 ` Dan Li
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20211123105149.GM1982710@arm.com \
--to=szabolcs.nagy@arm.com \
--cc=ashimida@linux.alibaba.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=linux-hardening@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox