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 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.

Also, this incident demonstrates that we need better testing of our
ABI backward compatibility guarantees.  Automation for taking all of
the test binaries from glibc-2.x and running them against lib*.so from
glibc-2.y (y > x), or something like that.  Probably Joseph is in the
best position to know how hard that would be.

zw


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