Re: [PATCH 1/2] Linux/x86: Update cancel_jmp_buf to match __jmp_buf_tag [BZ #22563]

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

On Thu, Dec 7, 2017 at 11:25 AM, Florian Weimer <fweimer@redhat.com> wrote:
> On 12/07/2017 08:19 PM, H.J. Lu wrote:
>>
>> On Thu, Dec 7, 2017 at 11:14 AM, Florian Weimer <fweimer@redhat.com>
>> wrote:
>>>
>>> On 12/07/2017 08:12 PM, H.J. Lu wrote:
>>>>>
>>>>>
>>>>> Sorry, what exactly is stored on the shadow stack?  I assumed it was
>>>>> for
>>>>> verification of the targets of ret instructions.
>>>>>
>>>>> In this case, don't need to unwind the shadow stack (or preserve its
>>>>> contents) because there are no returns from existing stack frames once
>>>>> cancellation has started.
>>>>>
>>>> Shadow stack is the similar to normal call stack without local
>>>> variables.
>>>> SHSTK checks  the return address of EACH  "RET"  instruction against
>>>> shadow stack.
>>>
>>>
>>>
>>> Then the shadow stack contents at the time of cancellation does not
>>> matter
>>> because all future RET instructions on this thread will match CALLs which
>>> happened *after* cancellation.  (In other words, I still think I'm right
>>> about this.)
>>>
>>
>> We are updating setjmp/lonjmp to save and restore shadow stack pointer:
>>
>>
>> https://sourceware.org/git/?p=glibc.git;a=commit;h=ac195a2d554e3fb577e44474faf3ed7f4521de9f
>
>
> Please try to understand what I wrote.  You don't need the restore during
> cancellation handling:
>
>     if (__glibc_unlikely (__not_first_call))          \
>       {                                               \
>         __cancel_routine (__cancel_arg);              \
>         __pthread_unwind_next (&__cancel_buf);        \
>         /* NOTREACHED */                              \
>       }                                               \
>

Who will sync shadow stack with call stack?


-- 
H.J.