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: "Tsimbalist, Igor V" <igor dot v dot tsimbalist at intel dot com>
- To: "H.J. Lu" <hjl dot tools at gmail dot com>, 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>, "Tsimbalist, Igor V" <igor dot v dot tsimbalist at intel dot com>
- Date: Thu, 8 Mar 2018 12:24:18 +0000
- Subject: RE: [PATCH 0/2] nptl: Update struct pthread_unwind_buf
- Authentication-results: sourceware.org; auth=none
- Dlp-product: dlpe-windows
- Dlp-reaction: no-action
- Dlp-version: 11.0.0.116
- 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> <CAMe9rOpVQ9oEK0WYdPvR_1nuvkpwXy3Rsy5UYsXvOnScRu2toA@mail.gmail.com> <CAMe9rOp_b2vtkJqc=0vf1rzk2==e3YA4W4Dvkp=FqopmswfoLg@mail.gmail.com>
> -----Original Message-----
> From: H.J. Lu [mailto:hjl.tools@gmail.com]
> Sent: Wednesday, March 7, 2018 11:07 PM
> To: Carlos O'Donell <carlos@redhat.com>; Tsimbalist, Igor V
> <igor.v.tsimbalist@intel.com>
> Cc: Florian Weimer <fw@deneb.enyo.de>; GNU C Library <libc-
> alpha@sourceware.org>
> Subject: Re: [PATCH 0/2] nptl: Update struct pthread_unwind_buf
>
> On Wed, Mar 7, 2018 at 12:14 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
> > 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.
> >
>
> Here is the GCC patch:
>
>
> diff --git a/gcc/calls.c b/gcc/calls.c
> index 19c95b8455b..d1f436dfa91 100644
> --- a/gcc/calls.c
> +++ b/gcc/calls.c
> @@ -604,7 +604,7 @@ special_function_p (const_tree fndecl, int flags)
> name_decl = DECL_NAME (cgraph_node::get (fndecl)->orig_decl);
>
> if (fndecl && name_decl
> - && IDENTIFIER_LENGTH (name_decl) <= 11
> + && IDENTIFIER_LENGTH (name_decl) <= 18
> /* Exclude functions not at the file scope, or not `extern',
> since they are not the magic functions we would otherwise
> think they are.
> @@ -637,8 +637,8 @@ special_function_p (const_tree fndecl, int flags)
> }
>
> /* ECF_RETURNS_TWICE is safe even for -ffreestanding. */
> - if (! strcmp (tname, "setjmp")
> - || ! strcmp (tname, "sigsetjmp")
> + if (! strncmp (tname, "setjmp", 6)
> + || ! strncmp (tname, "sigsetjmp", 9)
> || ! strcmp (name, "savectx")
> || ! strcmp (name, "vfork")
> || ! strcmp (name, "getcontext"))
Should it be compared with the whole function name (__setjmp_cancel and
__sigsetjmp_cancel) as something like setjmp_my_func will be also detected?
Also there was an error in detection of __getcontext, which is 12 bytes, but it
will be fixed by this patch.
Igor
> --
> H.J.