This is the mail archive of the
libc-alpha@sourceware.org
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> <e3100ba9-587a-cbad-1b49-0b57f3d2457c@redhat.com>
On Thu, Dec 7, 2017 at 10:36 AM, Florian Weimer <fweimer@redhat.com> 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
> that.
>
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.
--
H.J.