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 11:47:15 -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>
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.
--
H.J.