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 Mon, Dec 18, 2017 at 5:19 AM, H.J. Lu <hjl.tools@gmail.com> wrote:
> On Mon, Dec 18, 2017 at 4:52 AM, Florian Weimer <fweimer@redhat.com> wrote:
>> On 12/18/2017 01:25 PM, H.J. Lu wrote:
>>>
>>> If we don't restore shadow stack pointer, when we jump back to
>>> tst-foo.c:45,
>>> shadow stack won't match call stack when threadfunc () returns.
>>
>>
>> But threadfunc never returns if the thread is canceled, so I'm still as
>> puzzled as before.  Sorry.
>
> True, threadfunc never returns.  Instead, it lonjmps back to
> start_thread:
>
> Thread 2 "tst-foo" hit Breakpoint 2, __longjmp ()
>     at ../sysdeps/unix/sysv/linux/x86_64/__longjmp.S:30
> 30 ENTRY(__longjmp)
> (gdb) bt
> #0  __longjmp () at ../sysdeps/unix/sysv/linux/x86_64/__longjmp.S:30
> #1  0x00007ffff7837f5f in __libc_siglongjmp (env=env@entry=0x7ffff7800eb0,
>     val=val@entry=1) at longjmp.c:39
> #2  0x00007ffff7bc899d in unwind_stop (version=<optimized out>,
>     actions=<optimized out>, exc_class=<optimized out>,
>     exc_obj=<optimized out>, context=<optimized out>,
>     stop_parameter=0x7ffff7800eb0) at unwind.c:94
> #3  0x00007ffff6df9b1e in _Unwind_ForcedUnwind_Phase2 (
>     exc=exc@entry=0x7ffff7801d70, context=context@entry=0x7ffff7800c40,
>     frames_p=frames_p@entry=0x7ffff7800b48)
>     at /export/gnu/import/git/sources/gcc/libgcc/unwind.inc:170
> #4  0x00007ffff6dfa170 in _Unwind_ForcedUnwind (exc=0x7ffff7801d70,
>     stop=stop@entry=0x7ffff7bc88e0 <unwind_stop>,
>     stop_argument=<optimized out>)
>     at /export/gnu/import/git/sources/gcc/libgcc/unwind.inc:217
> #5  0x00007ffff7bc8a84 in __GI___pthread_unwind (buf=<optimized out>)
>     at unwind.c:121
> #6  0x00007ffff7bc8aa4 in __GI___pthread_unwind_next (
>     buf=buf@entry=0x7ffff7800da0) at unwind.c:136
> #7  0x0000000000400e4f in threadfunc (closure=<optimized out>) at tst-foo.c:44
> #8  0x00007ffff7bbfcde in start_thread (arg=<optimized out>)
>     at pthread_create.c:463
> #9  0x00007ffff78f5f73 in clone ()
>     at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
> (gdb)
> 104 jmpq *%rdx
> (gdb)  next
> start_thread (arg=<optimized out>) at pthread_create.c:436
> 436   if (__glibc_likely (! not_first_call))
> (gdb) bt
> #0  start_thread (arg=<optimized out>) at pthread_create.c:436
> #1  0x00007ffff78f5f73 in clone ()
>     at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
> (gdb) list
> 431   unwind_buf.priv.data.prev = NULL;
> 432   unwind_buf.priv.data.cleanup = NULL;
> 433
> 434   int not_first_call;
> 435   not_first_call = setjmp ((struct __jmp_buf_tag *)
> unwind_buf.cancel_jmp_buf);
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> This has to save and restore shadow stack pointer.   Since we only have
> one __sigsetjmp and one __longjmp, when shadow stack is enabled, they
> have to save and restore shadow stack pointer.  It means cancel_jmp_buf
> has to match __jmp_buf_tag.
>
> 436   if (__glibc_likely (! not_first_call))
> 437     {
> 438       /* Store the new cleanup handler info.  */
> 439       THREAD_SETMEM (pd, cleanup_jmp_buf, &unwind_buf);
> 440
> (gdb)
>
> Does it answer your question?
>

Here is the updated patch with commit message:

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.  Otherwise when shadow stack is enabled,
setjmp and longjmp will write and read beyond cancel_jmp_buf when saving
and restoring shadow stack pointer.

Does it look OK?

Thanks.

-- 
H.J.

Attachment: 0001-Linux-x86-Update-cancel_jmp_buf-to-match-__jmp_buf_t.patch
Description: Binary data