public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Carlos O'Donell <carlos@redhat.com>
To: "H.J. Lu" <hjl.tools@gmail.com>, Florian Weimer <fw@deneb.enyo.de>
Cc: Joseph Myers <joseph@codesourcery.com>,
	"Tsimbalist, Igor V" <igor.v.tsimbalist@intel.com>,
	GNU C Library <libc-alpha@sourceware.org>
Subject: Re: [PATCH] x86: Use pad in pthread_unwind_buf to preserve shadow stack register
Date: Fri, 06 Apr 2018 04:46:00 -0000	[thread overview]
Message-ID: <61a5b452-e59e-dfef-4530-a94a60480961@redhat.com> (raw)
In-Reply-To: <CAMe9rOpj6nYdP33emmepZ+KWFG2JDVNsHn1bve3oo5WQyFmduA@mail.gmail.com>

On 03/30/2018 12:41 PM, H.J. Lu wrote:
> On Thu, Mar 29, 2018 at 1:20 PM, Florian Weimer <fw@deneb.enyo.de> wrote:
>> * H. J. Lu:
>>
>>> On Thu, Mar 29, 2018 at 1:15 PM, Florian Weimer <fw@deneb.enyo.de> wrote:
>>>> * H. J. Lu:
>>>>
>>>>> You need to make a choice.  You either don't introduce a new symbol
>>>>> version or don't save shadow stack for thread cancellation.  You
>>>>> can't have both.
>>>> I don't understand.  We have room to save the shadow stack pointer in
>>>> the existing struct.
>>> No, we don't have room in struct pthread_unwind_buf:
>>>
>>> Note: There is an unused pointer space in pthread_unwind_buf_data.  But
>>> it isn't suitable for saving and restoring shadow stack register since
>>> x32 is a 64-bit process with 32-bit software pointer and kernel may
>>> place x32 shadow stack above 4GB.  We need to save and restore 64-bit
>>> shadow stack register for x32.
>> We have for void * fields.  They are subsequently overwritten by
>> __pthread_register_cancel.  But __sigsetjmp can write to them first
>> without causing any harm.  We just need a private __longjmp_cancel
>> that doesn't restore the shadow stack pointer.
> Here is the patch which does that.   Any comments?
 
OK, so I have reviewed https://github.com/hjl-tools/glibc/ hjl/cet/master,
please confirm that this is the correct branch of the required implementation
for CET. It really helps to review the rest of the patch set, you should be
preparing this as a patch set instead of having it reviewed one-at-a-time.
This issue was already raised in the thread with Zack.

Architecture:

* We avoid a "flag day" with feature_1 TCB flag to switch to a new ABI,
  which we have discussed is a fragile process which should be avoided if
  a supportable alternative solution exists.

* We avoid versioned symbols, this makes CET backportable, and this has a
  bigger benefit for long-term stable distributions.

* A key design problem has been that cancellation jump buffers within glibc
  are truncated to optimize on-stack size, and this means that setjmp could
  write beyond the structure because setjmp now tries to save the shadowstack
  pointer into space that the cancellation jump buffer did not allocate.
  For the record this optimization seems premature and I'm sad we did it, this
  is a lesson we should learn from.

* We have all agreed to the following concepts:

  * The cancellation process, in particular the unwinder, never returns from
    any of the functions we call, it just keeps calling into the unwinder to
    jump to the next unwound cancellation function all the way to the thread
    start routine. Therefore because we never return from one of these functions
    we never need to restore the shadow stack, and consequently wherever it is
    stored in the cancellation jump buffer can be overwritten if we need the
    space (it's a dead store).

    * The corollary to this is that function calls made from cancellation handlers
      will continue to advance the shadowstack from the deepest point at which
      cancellation is initiated from. This means that the depth of the shadowstack
      doesn't match the depth of the real stack while we are unwinding. I don't
      know if this will have consequences on analysis tooling or not, or debug
      tools during unwinding. It's a fairly advanced situation and corner case,
      and restoring the shadowstack is not useful becuase we don't need it and
      simplifies the implementation.

  * The cancellation jump buffer has private data used for chaining the cancel
    jump buffers together such that the custom unwinder can follow them and
    call them in sequence. This space constitutes 4 void *'s which is space
    that setjmp can write to, because we will just overwrite it when we register
    the cancel handler.

  * If the new shadowstack-enabled setjmp stores the shadowstack pointer into
    the space taken by the 4 void*'s then we won't overflow the stack, and we
    don't need to change the layout of the cancellation jump buffer. The 4 void*'s
    are sufficient, even for x32 to write a 64-bit shadow stack address.

* After fixing the cancellation jump buffers the following work needs to be reviewed:

  * Add feature_1 in tcb head to track CET status and make it easily available
    to runtime for checking.

  * Save and restore shadowstack in setjmp/longjmp.

  * Add CET support to ld.so et. al. and track runtime status.

  * Adjust vfork for shadow stack usage.

  * Add ENDBR or NOTRACK where required in assembly.

  * CET and makecontext incompatible.
    - Probably need to discuss which default is appropriate.
    - Should the user get CET automatically disabled in makecontext() et. al. silently?
    - Should your current solution, which is to error out during the build, and require
      flag changes, be the default? This forces the user to review the security for their
      application.

  * prctl for CET.

* The work to review after this patch appears to be less contentious in terms of
  the kinds of changes that are required. Most of the changes are internal details
  of enabling CET and not ABI details, with the exception of the possible pain we
  might cause with makecontext() being unsupported and what default position to take
  there.

Design:

* Overall the implementation looks exactly how I might expect it to look, but some
  of the math that places the shadowstack pointer appears to need either commenting
  or fixing because I don't understand it. You need to make it easy for me to see
  that we have placed the shadowstack pointer into the 4 pad words.

Details:

* One comment needs filling out a bit more, noted below.

> 0001-x86-Use-pad-in-pthread_unwind_buf-to-preserve-shadow.patch
> 
> 
> From f222537447f5ec879427f318b7c0396362b7453a Mon Sep 17 00:00:00 2001
> From: "H.J. Lu" <hjl.tools@gmail.com>
> Date: Sat, 24 Feb 2018 17:23:54 -0800
> Subject: [PATCH] x86: Use pad in pthread_unwind_buf to preserve shadow stack
>  register
> 
> The pad array in struct pthread_unwind_buf is used by setjmp to save
> shadow stack register.  We assert that size of struct pthread_unwind_buf
> is no less than offset of shadow stack pointer + shadow stack pointer
> size.
> 

OK.

> Since functions, like LIBC_START_MAIN, START_THREAD_DEFN as well as
> these with thread cancellation, call setjmp, but never return after
> __libc_unwind_longjmp, __libc_unwind_longjmp, which is defined as
> __libc_longjmp on x86, doesn't need to restore shadow stack register.

OK.

> __libc_longjmp, which is a private interface for thread cancellation
> implementation in libpthread, is changed to call __longjmp_cancel,
> instead of __longjmp.  __longjmp_cancel is a new internal function
> in libc, which is similar to __longjmp, but doesn't restore shadow
> stack register.

OK. Good. I like the use of a __longjmp_cancel name to call out what's
going on in the API (clear semantics).

> 
> The compatibility longjmp and siglongjmp in libpthread.so are changed
> to call __libc_siglongjmp, instead of __libc_longjmp, so that they will
> restore shadow stack register.

OK.

> 
> Tested with build-many-glibcs.py.
> 
> 	* nptl/pthread_create.c (START_THREAD_DEFN): Clear previous
> 	handlers after setjmp.
> 	* setjmp/longjmp.c (__libc_longjmp): Don't define alias if
> 	defined.
> 	* sysdeps/unix/sysv/linux/x86/setjmpP.h (_JUMP_BUF_SIGSET_NSIG):
> 	Changed to 97.
> 	* sysdeps/x86/Makefile (sysdep_routines): Add __longjmp_cancel.
> 	* sysdeps/x86/__longjmp_cancel.S: New file.
> 	* sysdeps/x86/longjmp.c: Likewise.
> 	* sysdeps/x86/nptl/pt-longjmp.c: Likewise.

This looks much better.

> ---
>  nptl/pthread_create.c                 |  9 ++--
>  setjmp/longjmp.c                      |  2 +
>  sysdeps/unix/sysv/linux/x86/setjmpP.h |  4 +-
>  sysdeps/x86/Makefile                  |  4 ++
>  sysdeps/x86/__longjmp_cancel.S        | 20 ++++++++
>  sysdeps/x86/longjmp.c                 | 45 ++++++++++++++++
>  sysdeps/x86/nptl/pt-longjmp.c         | 97 +++++++++++++++++++++++++++++++++++
>  7 files changed, 176 insertions(+), 5 deletions(-)
>  create mode 100644 sysdeps/x86/__longjmp_cancel.S
>  create mode 100644 sysdeps/x86/longjmp.c
>  create mode 100644 sysdeps/x86/nptl/pt-longjmp.c
> 
> diff --git a/nptl/pthread_create.c b/nptl/pthread_create.c
> index caaf07c134..1c5b3780c6 100644
> --- a/nptl/pthread_create.c
> +++ b/nptl/pthread_create.c
> @@ -427,12 +427,15 @@ START_THREAD_DEFN
>       compilers without that support we do use setjmp.  */
>    struct pthread_unwind_buf unwind_buf;
>  
> -  /* No previous handlers.  */
> +  int not_first_call;
> +  not_first_call = setjmp ((struct __jmp_buf_tag *) unwind_buf.cancel_jmp_buf);
> +
> +  /* No previous handlers.  NB: This must be done after setjmp since
> +     the same space may be used by setjmp to store extra data which
> +     should never be used by __libc_unwind_longjmp.  */

Suggest:
~~~
No previous handlers.  NB: This must be done after setjmp since
the private space in the unwind jump buffer may overlap space
used by setjmp to store extra architecture-specific information
which is never be used by the cancellation-specific 
__libc_unwind_longjmp.

The private space is allowed to overlap because the unwinder never
has to return through any of the jumped-to call frames, and thus
only a minimum amount of saved data need be stored, and for example,
need not include the process signal mask information. This is all
an optimization to reduce stack usage when pushing cancellation
handlers.
~~~

>    unwind_buf.priv.data.prev = NULL;
>    unwind_buf.priv.data.cleanup = NULL;
>  
> -  int not_first_call;
> -  not_first_call = setjmp ((struct __jmp_buf_tag *) unwind_buf.cancel_jmp_buf);

OK.

>    if (__glibc_likely (! not_first_call))
>      {
>        /* Store the new cleanup handler info.  */
> diff --git a/setjmp/longjmp.c b/setjmp/longjmp.c
> index a2a7065a85..453889e103 100644
> --- a/setjmp/longjmp.c
> +++ b/setjmp/longjmp.c
> @@ -40,9 +40,11 @@ __libc_siglongjmp (sigjmp_buf env, int val)
>  }
>  
>  #ifndef __libc_siglongjmp
> +# ifndef __libc_longjmp
>  /* __libc_longjmp is a private interface for cancellation implementation
>     in libpthread.  */
>  strong_alias (__libc_siglongjmp, __libc_longjmp)
> +# endif

OK.

>  weak_alias (__libc_siglongjmp, _longjmp)
>  weak_alias (__libc_siglongjmp, longjmp)
>  weak_alias (__libc_siglongjmp, siglongjmp)
> diff --git a/sysdeps/unix/sysv/linux/x86/setjmpP.h b/sysdeps/unix/sysv/linux/x86/setjmpP.h
> index c0ed767a0d..90a6bbcf32 100644
> --- a/sysdeps/unix/sysv/linux/x86/setjmpP.h
> +++ b/sysdeps/unix/sysv/linux/x86/setjmpP.h
> @@ -22,8 +22,8 @@
>  #include <bits/types/__sigset_t.h>
>  
>  /* The biggest signal number + 1.  As of kernel 4.14, x86 _NSIG is 64.
> -   Define it to 513 to leave some rooms for future use.  */
> -#define _JUMP_BUF_SIGSET_NSIG	513
> +   Define it to 97 to leave some rooms for future use.  */

OK.

> +#define _JUMP_BUF_SIGSET_NSIG	97

Please provide proof in the way of a comment or rewriting this constant
to show that it places the shadow stack pointer on both x86_64 and x32
into the range of the private pad.

Also, from commit  f33632ccd1dec3217583fcfdd965afb62954203c,
where did this math come from?

((_JUMP_BUF_SIGSET_NSIG - 1 + 7) / (8 * sizeof (unsigned long int)))

Why the +7?

>  /* Number of longs to hold all signals.  */
>  #define _JUMP_BUF_SIGSET_NWORDS \
>    ((_JUMP_BUF_SIGSET_NSIG - 1 + 7) / (8 * sizeof (unsigned long int)))
> diff --git a/sysdeps/x86/Makefile b/sysdeps/x86/Makefile
> index 0d0326c21a..d25d6f0ae4 100644
> --- a/sysdeps/x86/Makefile
> +++ b/sysdeps/x86/Makefile
> @@ -8,3 +8,7 @@ sysdep-dl-routines += dl-get-cpu-features
>  tests += tst-get-cpu-features
>  tests-static += tst-get-cpu-features-static
>  endif
> +
> +ifeq ($(subdir),setjmp)
> +sysdep_routines += __longjmp_cancel
> +endif

OK.

> diff --git a/sysdeps/x86/__longjmp_cancel.S b/sysdeps/x86/__longjmp_cancel.S
> new file mode 100644
> index 0000000000..b57dbfa376
> --- /dev/null
> +++ b/sysdeps/x86/__longjmp_cancel.S
> @@ -0,0 +1,20 @@
> +/* __longjmp_cancel for x86.
> +   Copyright (C) 2018 Free Software Foundation, Inc.
> +   This file is part of the GNU C Library.
> +
> +   The GNU C Library is free software; you can redistribute it and/or
> +   modify it under the terms of the GNU Lesser General Public
> +   License as published by the Free Software Foundation; either
> +   version 2.1 of the License, or (at your option) any later version.
> +
> +   The GNU C Library is distributed in the hope that it will be useful,
> +   but WITHOUT ANY WARRANTY; without even the implied warranty of
> +   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> +   Lesser General Public License for more details.
> +
> +   You should have received a copy of the GNU Lesser General Public
> +   License along with the GNU C Library; if not, see
> +   <http://www.gnu.org/licenses/>.  */
> +
> +#define __longjmp __longjmp_cancel
> +#include <__longjmp.S>

OK.

> diff --git a/sysdeps/x86/longjmp.c b/sysdeps/x86/longjmp.c
> new file mode 100644
> index 0000000000..a53f31e1dd
> --- /dev/null
> +++ b/sysdeps/x86/longjmp.c
> @@ -0,0 +1,45 @@
> +/* __libc_siglongjmp for x86.
> +   Copyright (C) 2018 Free Software Foundation, Inc.
> +   This file is part of the GNU C Library.
> +
> +   The GNU C Library is free software; you can redistribute it and/or
> +   modify it under the terms of the GNU Lesser General Public
> +   License as published by the Free Software Foundation; either
> +   version 2.1 of the License, or (at your option) any later version.
> +
> +   The GNU C Library is distributed in the hope that it will be useful,
> +   but WITHOUT ANY WARRANTY; without even the implied warranty of
> +   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> +   Lesser General Public License for more details.
> +
> +   You should have received a copy of the GNU Lesser General Public
> +   License along with the GNU C Library; if not, see
> +   <http://www.gnu.org/licenses/>.  */
> +
> +#define __libc_longjmp __redirect___libc_longjmp
> +#include <setjmp/longjmp.c>
> +#undef __libc_longjmp
> +
> +extern void __longjmp_cancel (__jmp_buf __env, int __val)
> +     __attribute__ ((__noreturn__)) attribute_hidden;
> +
> +/* Since __libc_longjmp is a private interface for cancellation
> +   implementation in libpthread, there is no need to restore shadow
> +   stack register.  */
> +
> +void
> +__libc_longjmp (sigjmp_buf env, int val)
> +{
> +  /* Perform any cleanups needed by the frames being unwound.  */
> +  _longjmp_unwind (env, val);

OK.

> +
> +  if (env[0].__mask_was_saved)
> +    /* Restore the saved signal mask.  */
> +    (void) __sigprocmask (SIG_SETMASK,
> +			  (sigset_t *) &env[0].__saved_mask,
> +			  (sigset_t *) NULL);

OK.

> +
> +  /* Call the machine-dependent function to restore machine state
> +     without shadow stack.  */
> +  __longjmp_cancel (env[0].__jmpbuf, val ?: 1);

OK.

> +}
> diff --git a/sysdeps/x86/nptl/pt-longjmp.c b/sysdeps/x86/nptl/pt-longjmp.c
> new file mode 100644
> index 0000000000..7eb8651cfe
> --- /dev/null
> +++ b/sysdeps/x86/nptl/pt-longjmp.c
> @@ -0,0 +1,97 @@
> +/* ABI compatibility for 'longjmp' and 'siglongjmp' symbols in libpthread ABI.
> +   X86 version.
> +   Copyright (C) 18 Free Software Foundation, Inc.
> +   This file is part of the GNU C Library.
> +
> +   The GNU C Library is free software; you can redistribute it and/or
> +   modify it under the terms of the GNU Lesser General Public
> +   License as published by the Free Software Foundation; either
> +   version 2.1 of the License, or (at your option) any later version.
> +
> +   The GNU C Library is distributed in the hope that it will be useful,
> +   but WITHOUT ANY WARRANTY; without even the implied warranty of
> +   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> +   Lesser General Public License for more details.
> +
> +   You should have received a copy of the GNU Lesser General Public
> +   License along with the GNU C Library; if not, see
> +   <http://www.gnu.org/licenses/>.  */
> +
> +/* <nptl/descr.h> has
> +
> +struct pthread_unwind_buf
> +{
> +  struct
> +  {
> +    __jmp_buf jmp_buf;
> +    int mask_was_saved;
> +  } cancel_jmp_buf[1];
> +
> +  union
> +  {
> +    void *pad[4];
> +    struct
> +    {
> +      struct pthread_unwind_buf *prev;
> +      struct _pthread_cleanup_buffer *cleanup;
> +      int canceltype;
> +    } data;
> +  } priv;
> +};
> +
> +  The pad array in struct pthread_unwind_buf is used by setjmp to save

This appears to be SHADOW_STACK_POINTER_OFFSET in subsequent patches.

However on your hjl/cet/master branch it appears that this offset is not
defined to be *just after* the mask_was_saved?

> +  shadow stack register.  Assert that size of struct pthread_unwind_buf
> +  is no less than offset of shadow stack pointer plus shadow stack
> +  pointer size.
> +
> +  NB: setjmp is called in libpthread to save shadow stack register.  But
> +  __libc_unwind_longjmp doesn't restore shadow stack register since they
> +  never return after longjmp.  */
> +
> +#include <pthreadP.h>
> +#include <jmp_buf-ssp.h>
> +
> +#ifdef __x86_64__
> +# define SHADOW_STACK_POINTER_SIZE 8
> +#else
> +# define SHADOW_STACK_POINTER_SIZE 4
> +#endif
> +
> +_Static_assert ((sizeof (struct pthread_unwind_buf)
> +		 >= (SHADOW_STACK_POINTER_OFFSET
> +		     + SHADOW_STACK_POINTER_SIZE)),
> +		"size of struct pthread_unwind_buf < "
> +		"(SHADOW_STACK_POINTER_OFFSET + SHADOW_STACK_POINTER_SIZE)");

OK.

> +
> +#include <shlib-compat.h>
> +
> +/* libpthread once had its own longjmp (and siglongjmp alias), though there
> +   was no apparent reason for it.  There is no use in having a separate
> +   symbol in libpthread, but the historical ABI requires it.  For static
> +   linking, there is no need to provide anything here--the libc version
> +   will be linked in.  For shared library ABI compatibility, there must be
> +   longjmp and siglongjmp symbols in libpthread.so.
> +
> +   With an IFUNC resolver, it would be possible to avoid the indirection,
> +   but the IFUNC resolver might run before the __libc_longjmp symbol has
> +   been relocated, in which case the IFUNC resolver would not be able to
> +   provide the correct address.  */
> +
> +#if SHLIB_COMPAT (libpthread, GLIBC_2_0, GLIBC_2_22)
> +
> +static void __attribute__ ((noreturn, used))
> +longjmp_compat (jmp_buf env, int val)
> +{
> +  /* NB: We call __libc_siglongjmp,  instead of __libc_longjmp, since
> +     __libc_longjmp is a private interface for cancellation which
> +     doesn't restore shadow stack register.  */
> +  __libc_siglongjmp (env, val);

OK.

> +}
> +
> +strong_alias (longjmp_compat, longjmp_alias)
> +compat_symbol (libpthread, longjmp_alias, longjmp, GLIBC_2_0);
> +
> +strong_alias (longjmp_alias, siglongjmp_alias)
> +compat_symbol (libpthread, siglongjmp_alias, siglongjmp, GLIBC_2_0);
> +
> +#endif
> -- 2.14.3


-- 
Cheers,
Carlos.

  reply	other threads:[~2018-04-06  4:46 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-30 17:41 H.J. Lu
2018-04-06  4:46 ` Carlos O'Donell [this message]
2018-04-06 12:59   ` H.J. Lu
2018-04-06 20:26     ` H.J. Lu
2018-04-12 21:36       ` Carlos O'Donell
2018-04-12 21:36     ` Carlos O'Donell
2018-04-12 23:50       ` H.J. Lu
2018-04-21  3:28         ` [PATCHv2] " Carlos O'Donell
2018-04-21 18:37           ` [PATCH/v3] " H.J. Lu
2018-05-02  4:43             ` Carlos O'Donell
2018-05-02 12:45               ` H.J. Lu
2018-04-17 20:03     ` [PATCH] " Joseph Myers
2018-04-17 23:20       ` H.J. Lu

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

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

  git send-email \
    --in-reply-to=61a5b452-e59e-dfef-4530-a94a60480961@redhat.com \
    --to=carlos@redhat.com \
    --cc=fw@deneb.enyo.de \
    --cc=hjl.tools@gmail.com \
    --cc=igor.v.tsimbalist@intel.com \
    --cc=joseph@codesourcery.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).