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 07:59 PM, H.J. Lu wrote:
On Thu, Dec 7, 2017 at 10:36 AM, Florian Weimer <> 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

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.


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