Re: PING: [PATCH] x86: Add __sigsetjmp_cancel and __setjmp_cancel

["H.J. Lu" <hjl dot tools at gmail dot com>]

On Thu, Mar 29, 2018 at 10:48 AM, Zack Weinberg <zackw@panix.com> wrote:
> On Thu, Mar 29, 2018 at 1:37 PM, Zack Weinberg <zackw@panix.com> wrote:
>> On Thu, Mar 29, 2018 at 10:32 AM, H.J. Lu <hjl.tools@gmail.com> wrote:
>>> On Thu, Mar 22, 2018 at 1:59 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
>>>> On Fri, Mar 16, 2018 at 4:28 AM, H.J. Lu <hjl.tools@gmail.com> wrote:
>>>>> On Fri, Mar 16, 2018 at 1:24 AM, Florian Weimer <fw@deneb.enyo.de> wrote:
>>>>>> * H. J. Lu:
>>>>>>
>>>> Here is the updated patch.  OK for master?
>>>>
>>>>
>>>
>>> PING:
>>>
>>> https://sourceware.org/ml/libc-alpha/2018-03/msg00521.html
>
> HJ, you've been posting a long stream of one-off fixes to the shadow
> stack support code with no end in sight, and you seem to be in a
> terrible hurry about it, and speaking only for myself, those add up to
> me having no confidence that _any_ of the patches are correct.

The main challenge is adding __sigsetjmp_cancel and __setjmp_cancel,
which introduces a different set of setjmp/longjmp for thread cancellation.
The current set of glibc patches works now.  But they won't be finalized
until kernel patches are merged.

> Would you please consider halting the stream of code changes for long
> enough to write up a careful, thorough description of exactly what the
> shadow stack's requirements are and how they interact with _all_ of

Shadow stack is transparent to most functions in glibc.  The changes
are limited to a few functions.

> the C library's abnormal control flow features (at least:
> setjmp/longjmp, cancellation, C++ exceptions, threads, ucontext
> coroutines, regular old signals, and signals delivered to an
> alternative stack; and I'm sure I'm forgetting at least one more)?

1. C++ exception handing is handled in libgcc.  Glibc isn't involved.
2. setjmp/longjmp just needs to save and restore shadow stack.
3. Thread cancellation doesn't require to restore shadow stack.  There
are 2 ways to deal with it:
   a.  Save and restore shadow stacks when shadow stack is in use, which
       doesn't require new symbol version.
   b.  Don't save and restore shadow stacks, which requires new symbol
       version.
4.  Signal handling is handled by kernel and should be transparent to glibc,
      including alternative signal stack/
5.  Shadow stack is incompatible with ucontext family functions since they
     can't properly set up and destroy shadow stack.  For the time being, it
      is an error to use shadow stack with <ucontext.h>.  I'd like to get inputs
     on how to support shadow stack in ucontext family functions.

> Post _that_ for review. Only go back to the code changes when all of
> the x86 maintainers are satisfied that we know how this _ought_ to
> work.
>
> zw



-- 
H.J.