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 0/2] nptl: Update struct pthread_unwind_buf


On Wed, Mar 7, 2018 at 11:47 AM, H.J. Lu <hjl.tools@gmail.com> wrote:
> On Wed, Mar 7, 2018 at 9:34 AM, Carlos O'Donell <carlos@redhat.com> wrote:
>> On 03/07/2018 03:56 AM, H.J. Lu wrote:
>>>>> 1. I have to add  __setjmp_cancel and __sigsetjmp_cancel which won't
>>>>> save and restore shadow stack register.
>>>
>>> I have been testing this.  I ran into one issue.  GCC knows that setjmp will
>>> return via longjmp and inserts ENDBR after it.  But it doesn't know
>>>   __setjmp_cancel and __sigsetjmp_cancel.   We can either add them to GCC
>>> or add NOTRACK prefix to the corresponding longjmps.
>>
>> I would rather GCC did not know about these implementation details.
>>
>> I have no objection to the NOTRACK prefix in the corresponding longjmps.
>>
>> What would be a downside to this choice?
>>
>
> NOTRACK prefix is typically generated by compiler for switch table.  Compiler
> knows each indirect jump target is valid and pointer load for indirect jump is
> generated by compiler in read-only section.  This is pretty safe since there is
> very little chance for malicious codes to temper the pointer value.  However,
> in case of longjmp, the indirect jump target is in jmpbuf.   There is
> a possilibty
> for malicious codes to change the indirect jump target such that longjmp wil
> jump to the wrong place.  Use NOTRACK prefix here defeats the purpose of
> indirect branch tracking in CET.
>

Also GCC needs to know that __setjmp_cancel and __sigsetjmp_cancel may
return twice, similar to setjmp.


-- 
H.J.


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