All of lore.kernel.org
 help / color / mirror / Atom feed
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
> 

  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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.