This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: RFA: Need to extend x86 psABI to support thread cancellation and alternate signal stack


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]