This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Revert Intel CET changes to __jmp_buf_tag (Bug 22743)
On Thu, Jan 25, 2018 at 6:55 AM, Zack Weinberg <zackw@panix.com> wrote:
> On Thu, Jan 25, 2018 at 8:00 AM, H.J. Lu <hjl.tools@gmail.com> wrote:
>> 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.
>
> In my opinion, the fact that you two are having this argument
> reinforces Carlos' position: the original patch should be reverted and
> we should figure out what to do in 2.28 when we're not under time
> pressure. HJ, do you have some concrete external reason why you must
> have this new feature in 2.27? If so, please tell us what it is. To
> me it doesn't seem urgent.
My question is if we are going to fix it at all. If yes, why not 2.27.
Both approaches are opaque to users. They can't tell the difference.
--
H.J.