This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

On 12/07/2017 08:19 PM, H.J. Lu wrote:
On Thu, Dec 7, 2017 at 11:14 AM, Florian Weimer <> 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:;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 */			      \
      }						      \


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]