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.
next prev parent 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).