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.

FWIW, this approach doesn't work with x32 which is 64-bit process with
32-bit software pointer.  Kernel may place shadow stack above 4GB.
We need to save and restore 64-bit shadow stack register for x32.

-- 
H.J.


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