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

[Florian Weimer]

On 12/07/2017 07:59 PM, H.J. Lu wrote:
> On Thu, Dec 7, 2017 at 10:36 AM, Florian Weimer <fweimer@redhat.com> wrote:
>> On 12/07/2017 06:40 PM, H.J. Lu wrote:
>>>
>>> On x86, padding in struct __jmp_buf_tag is used for shadow stack pointer
>>> to support shadow stack in Intel Control-flow Enforcemen Technology.
>>> Since the cancel_jmp_buf array is passed to setjmp and longjmp by
>>> casting it to pointer to struct __jmp_buf_tag, it should be as large
>>> as struct __jmp_buf_tag.  This patch adds pthread.h, pthreaddef.h and
>>> pthreadP.h for Linux/x86 to define a new cancel_jmp_buf to match
>>> struct __jmp_buf_tag.
>>
>>
>> This seems the wrong thing to do.
>>
>> I don't think cancellation needs the shadow stack because none of the
>> functions on the existing stack return during cancellation processing.
>>
>> Furthermore, SJLJ-style cancellation appears to defeat CET anyway, so I'm
>> puzzled why aren't trying to get rid of this type of cancellation
>> implementation instead because it looks like a fairly significant weakness
>> (similar to SEH on Windows).
>>
>> If you want to preserve SJLJ-style cancellation as-is,
>> __pthread_unwind_buf_t has sufficient padding, and you could simply use
>> that.
>>
> 
> No, shadow stack doesn't work that way.  Once it is turned on, it is on
> until the process exits.   There is no such a thing of that cancellation
> doesn't need shadow stack.

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.

Florian