Re: [PATCH 0/2] nptl: Update struct pthread_unwind_buf

[Carlos O'Donell <carlos@redhat.com>]

On 02/09/2018 04:34 AM, H.J. Lu wrote:
> On Fri, Feb 9, 2018 at 4:11 AM, Florian Weimer <fw@deneb.enyo.de> wrote:
>> * H. J. Lu:
>>
>>>> My proposal is still rather hackish, but so is the existing code (the
>>>
>>> A pointer to a buffer in user program is passed to libpthread.
>>> There is a jmp buf in the buffer followed by other fields.  Since
>>> the size of jmp buf is increased in glibc 2.28, we need to know the
>>> offset of other fields. Otherwise libpthread may write beyond the
>>> buffer in user program.  I don't see how symbol versioning can help
>>> us here since the INTERNAL libpthread functions don't know the
>>> layout of __pthread_unwind_buf_t of USER programs.
>>
>> I suggest *not* to increase the size of the jump buffer.
> 
> Where do we save shadow stack pointer?

typedef struct
{
  struct
  {
    __jmp_buf __cancel_jmp_buf;
    int __mask_was_saved;
  } __cancel_jmp_buf[1];


  void *__pad[4];
  ^^^^^^^^^^^^^^^ Save the shadow stack pointer here.


} __pthread_unwind_buf_t __attribute__ ((__aligned__));

Save the shadow stack pointer to __pad[4] by making the
internal sigset_t smaller and moving it down.

The key aspect of Florian's recommendation is a realization
that a pthread_cleanup_pop can only restore you to the *same*
function e.g. the earlier pthread_cleanup_push, and therefore
does not need to change the shadow stack pointer.

All subsequent unwinding will proceed from one jump buffer
to the next, and through the unwinder, until it reaches
pthread_create. When will we ever return via a normal return
instruction and need to verify via the shadow stack?

-- 
Cheers,
Carlos.