This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 0/2] nptl: Update struct pthread_unwind_buf
- From: "H.J. Lu" <hjl dot tools at gmail dot com>
- To: "Carlos O'Donell" <carlos at redhat dot com>
- Cc: Florian Weimer <fw at deneb dot enyo dot de>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Wed, 7 Mar 2018 12:14:12 -0800
- Subject: Re: [PATCH 0/2] nptl: Update struct pthread_unwind_buf
- Authentication-results: sourceware.org; auth=none
- References: <20180201205757.51911-1-hjl.tools@gmail.com> <87a7vyjsqv.fsf@mid.deneb.enyo.de> <CAMe9rOrkNQudxKwPmrOkrWD7URO+mzdOeQhNqMns2a2QSq0S7g@mail.gmail.com> <87vaelbetu.fsf@mid.deneb.enyo.de> <CAMe9rOqCPk55Ke9T+0194myAiQHwKZVv=gzm3pHDtULTaT0S3A@mail.gmail.com> <87fu5pb7ql.fsf@mid.deneb.enyo.de> <CAMe9rOofbxtenVEP8sQSi4-0TAn6gsRBWi88RyzchwaxvEtGeA@mail.gmail.com> <CAMe9rOqowauyuyvJg5sjktTJYkNJ3NcvXzLQ7mz_+5F9AXQrWw@mail.gmail.com> <877er1b4zp.fsf@mid.deneb.enyo.de> <CAMe9rOrZaz2RbcHBZ8MSjx0VaLpNxd=8RhmJoXmH0fps6qTYHA@mail.gmail.com> <87371pb3ga.fsf@mid.deneb.enyo.de> <CAMe9rOqPkq7gQ1e6EE-87kVuBnMZrqmOeNExQ1ZmGsqufZu3MQ@mail.gmail.com> <87tvu59o21.fsf@mid.deneb.enyo.de> <CAMe9rOqRz=YR78QqD_EqAagZ3yr1v8jqJvn2WuF=8KCJp9csfw@mail.gmail.com> <87po4t9mxt.fsf@mid.deneb.enyo.de> <CAMe9rOpcDM0hp_h1EomZrjaR2raSiS5kB-B0o6fFRBZ9ysA=Ew@mail.gmail.com> <3764b0a1-9f26-6f5f-1bc5-d374f2672f3a@redhat.com> <CAMe9rOrA+yv2E8u0NjAMMhPkpL5+rk6TuhCj7dhBiupryUGQ7w@mail.gmail.com> <86d5d5ba-2b53-1904-dada-3efe2b3ad501@redhat.com> <CAMe9rOqGDo4SpTQ=BBRK+RJcVVN3M9WQxwWFJjK+k=+nvTPAOg@mail.gmail.com>
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.