This is the mail archive of the libc-alpha@sourceware.org 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] Revert Intel CET changes to __jmp_buf_tag (Bug 22743)


On Thu, Jan 25, 2018 at 4:50 AM, Florian Weimer <fweimer@redhat.com> wrote:
> On 01/25/2018 01:38 PM, H.J. Lu wrote:
>>>
>>> I still think you are over-engineering this.  The pad array has still an
>>> unused member (the last one).  Just change sigsetjmp to store the shadow
>>> pointer in that location, then the old and new setjmp will work with the
>>> current stack layout.  As far as I can tell, there are only 64 signals,
>>> so
>>> you don't even have to change the location of the signal mask.
>>
>> No, it doesn't work.  struct pthread_unwind_buf is placed on caller's
>> stack
>> and its address is passed from applications to libpthread.   If the size
>> of
>> caller's struct pthread_unwind_buf is smaller than what libpthread
>> expects,
>> libpthread will override caller's stack.
>
>
> As far as I can see, ibuf->priv.pad[3] is currently unused.  (sig)setjmp
> could save the shadow stack pointer at the right offset in jmp_buf to hit
> this place, then all these new conditionals wouldn't be necessary. Of course
> it is still a hack, but your approach is not clearer IMHO.

It is a mistake to use different jmpbuf sizes in libpthread and libc.
My patch is much more straightforward than what you suggested.
But I can live with it if everyone thinks it is the way to go.

> The patch you posted is very different from the commit link you shared
> earlier.  I still need to review it in detail.
>

Yes, I reworked the legacy cleanup buffer detection.  Now it simply checks
if shadow stack is enabled or not.

-- 
H.J.


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