unofficial mirror of libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: "H.J. Lu" <hjl.tools@gmail.com>
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
Date: Wed, 7 Mar 2018 14:06:56 -0800	[thread overview]
Message-ID: <CAMe9rOp_b2vtkJqc=0vf1rzk2==e3YA4W4Dvkp=FqopmswfoLg@mail.gmail.com> (raw)
In-Reply-To: <CAMe9rOpVQ9oEK0WYdPvR_1nuvkpwXy3Rsy5UYsXvOnScRu2toA@mail.gmail.com>

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"))


-- 
H.J.


  reply	other threads:[~2018-03-07 22:04 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-01 20:57 [PATCH 0/2] nptl: Update struct pthread_unwind_buf H.J. Lu
2018-02-01 20:57 ` [PATCH 1/2] Revert "Revert Intel CET changes to __jmp_buf_tag (Bug 22743)" H.J. Lu
2018-02-01 20:57 ` [PATCH 2/2] nptl: Update struct pthread_unwind_buf [BZ #22743] H.J. Lu
2018-02-08  9:25 ` [PATCH 0/2] nptl: Update struct pthread_unwind_buf Carlos O'Donell
2018-02-08 11:55   ` Florian Weimer
2018-02-09  6:29     ` Carlos O'Donell
2018-02-09 10:48       ` Florian Weimer
2018-02-09 11:13         ` H.J. Lu
2018-02-09 12:11           ` Florian Weimer
2018-02-09 12:34             ` H.J. Lu
2018-02-09 14:13               ` H.J. Lu
2018-02-09 14:33                 ` Florian Weimer
2018-02-09 15:24                   ` H.J. Lu
2018-02-24  5:46               ` Carlos O'Donell
2018-02-24 15:19                 ` H.J. Lu
2018-02-24 15:46                   ` Florian Weimer
2018-02-25  2:04                     ` H.J. Lu
2018-02-25  9:26                       ` Florian Weimer
2018-02-25 11:37                         ` H.J. Lu
2018-02-25 11:59                           ` Florian Weimer
2018-02-25 12:53                             ` H.J. Lu
2018-02-25 12:55                               ` H.J. Lu
2018-02-25 12:58                                 ` Florian Weimer
2018-02-25 13:23                                   ` H.J. Lu
2018-02-25 13:31                                     ` Florian Weimer
2018-02-25 13:36                                       ` H.J. Lu
2018-02-25 13:49                                         ` H.J. Lu
2018-02-25 13:49                                         ` Florian Weimer
2018-02-25 14:00                                           ` H.J. Lu
2018-02-25 14:13                                             ` Florian Weimer
2018-02-26  3:55                                               ` H.J. Lu
2018-02-28 23:23                                                 ` Carlos O'Donell
2018-03-07 11:56                                                   ` H.J. Lu
2018-03-07 17:34                                                     ` Carlos O'Donell
2018-03-07 19:47                                                       ` H.J. Lu
2018-03-07 20:14                                                         ` H.J. Lu
2018-03-07 22:06                                                           ` H.J. Lu [this message]
2018-03-08 12:24                                                             ` Tsimbalist, Igor V
2018-03-08 12:48                                                               ` H.J. Lu
2018-03-09  0:47                                                                 ` Carlos O'Donell
2018-03-09  5:23                                                                   ` H.J. Lu
2018-03-15  4:20                                                                     ` Carlos O'Donell
2018-02-24  6:41         ` Carlos O'Donell
2018-02-08 13:27   ` H.J. Lu
2018-02-09  6:40     ` Carlos O'Donell

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/libc/involved.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAMe9rOp_b2vtkJqc=0vf1rzk2==e3YA4W4Dvkp=FqopmswfoLg@mail.gmail.com' \
    --to=hjl.tools@gmail.com \
    --cc=carlos@redhat.com \
    --cc=fw@deneb.enyo.de \
    --cc=igor.v.tsimbalist@intel.com \
    --cc=libc-alpha@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).