This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH 1/2] Linux/x86: Update cancel_jmp_buf to match __jmp_buf_tag [BZ #22563]
- From: "H.J. Lu" <hjl dot tools at gmail dot com>
- To: Florian Weimer <fweimer at redhat dot com>
- Cc: GNU C Library <libc-alpha at sourceware dot org>
- Date: Thu, 7 Dec 2017 10:59:42 -0800
- Subject: Re: [PATCH 1/2] Linux/x86: Update cancel_jmp_buf to match __jmp_buf_tag [BZ #22563]
- Authentication-results: sourceware.org; auth=none
- References: <20171207174057.GA32196@gmail.com> <email@example.com>
On Thu, Dec 7, 2017 at 10:36 AM, Florian Weimer <firstname.lastname@example.org> 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.