public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Florian Weimer <fweimer@redhat.com>
To: "H.J. Lu" <hjl.tools@gmail.com>
Cc: GNU C Library <libc-alpha@sourceware.org>,
	GCC Development <gcc@gcc.gnu.org>,
	Carlos O'Donell <carlos@redhat.com>
Subject: Re: RFA: Need to extend x86 psABI to support thread cancellation and alternate signal stack
Date: Tue, 27 Mar 2018 15:43:00 -0000	[thread overview]
Message-ID: <e4ce960d-452b-c610-9ad9-878f38591ef3@redhat.com> (raw)
In-Reply-To: <CAMe9rOrWO+j5c63H_uay9g4spTMCnGYbEVOMe7kVhJeDMz2gfg@mail.gmail.com>

On 03/27/2018 01:26 PM, H.J. Lu wrote:

> 2. Since shadow stack is never saved and restored by compiler, unwinder
> in libgcc counts how many stack frame it has to unwind and uses INCSSP
> to pop shadow stack.  This can't unwind the original shadow stack when
> the alternate shadow stack is used.  _URC_NO_REASON_CANCEL
> works only if longjmp will be used to finish stack unwinding, which is
> the case for thread cancellation in glibc.
> 
> Here are patches for GCC:
> 
> https://github.com/hjl-tools/gcc/commit/e9ff815941406e38fa629947af4d809b9129e860
> 
> and glibc:
> 
> https://github.com/hjl-tools/glibc/commit/1aec81528ab26aa8a8a7965317b6e1a8ba4526aa
> 
> They fixed the issue.

The patches are nice and short, but: Do they really fix the issue?  They 
make cancellation work again, but they do not fix the general unwinding 
issue with alternate signal handler stacks AFAICS.

>> It may be possible to implement this without kernel changes: Patch the
>> interrupted context to continue unwinding, and then call sigreturn to switch
>> both stacks at the same time.
>>
> 
> We passed almost all 5000+ tests in glibc with shadow stack and indirect
> branch tracking enabled. The only remaining failures are thread cancellation
> with alternate signal stack and -fasynchronous-unwind-tables.  I couldn't
> find a way to unwind shadow stack by counting stack frame when exception
> happens in alternate signal stack.

I'm not sure how comprehensive these tests are, considering that no one 
expected something like shadow stacks (maybe those dual ia64 stacks are 
somewhat similar, but I don't know anything about them).

Thanks,
Florian

  reply	other threads:[~2018-03-27 15:43 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-26 22:43 H.J. Lu
2018-03-27  6:31 ` Florian Weimer
2018-03-27 11:26   ` H.J. Lu
2018-03-27 15:43     ` Florian Weimer [this message]
2018-03-27 15:55       ` H.J. Lu
2018-03-28 13:04         ` H.J. Lu

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=e4ce960d-452b-c610-9ad9-878f38591ef3@redhat.com \
    --to=fweimer@redhat.com \
    --cc=carlos@redhat.com \
    --cc=gcc@gcc.gnu.org \
    --cc=hjl.tools@gmail.com \
    --cc=libc-alpha@sourceware.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).