public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
* [PATCH 1/2] Linux/x86: Update cancel_jmp_buf to match __jmp_buf_tag [BZ #22563]
@ 2017-12-07 17:41 H.J. Lu
  2017-12-07 17:58 ` Joseph Myers
  2017-12-07 18:37 ` Florian Weimer
  0 siblings, 2 replies; 63+ messages in thread
From: H.J. Lu @ 2017-12-07 17:41 UTC (permalink / raw)
  To: GNU C Library

On x86, padding in struct __jmp_buf_tag is used for shadow stack pointer
to support shadow stack in Intel Control-flow Enforcemen Technology.
Since the cancel_jmp_buf array is passed to setjmp and longjmp by
casting it to pointer to struct __jmp_buf_tag, it should be as large
as struct __jmp_buf_tag.  This patch adds pthread.h, pthreaddef.h and
pthreadP.h for Linux/x86 to define a new cancel_jmp_buf to match
struct __jmp_buf_tag.

Any comments?

H.J.
---
	[BZ #22563]
	* nptl/descr.h [NEED_SAVED_MASK_IN_CANCEL_JMP_BUF]
	(pthread_unwind_buf): Add saved_mask to cancel_jmp_buf.
	* sysdeps/unix/sysv/linux/x86/pthread.h: New file.
	* sysdeps/unix/sysv/linux/x86/pthreaddef.h: Likewise.
	* sysdeps/unix/sysv/linux/x86/nptl/pthreadP.h: Likewise.
---
 nptl/descr.h                                |    3 +
 sysdeps/unix/sysv/linux/x86/nptl/pthreadP.h |   36 +
 sysdeps/unix/sysv/linux/x86/pthread.h       | 1165 +++++++++++++++++++++++++++
 sysdeps/unix/sysv/linux/x86/pthreaddef.h    |   22 +
 4 files changed, 1226 insertions(+)
 create mode 100644 sysdeps/unix/sysv/linux/x86/nptl/pthreadP.h
 create mode 100644 sysdeps/unix/sysv/linux/x86/pthread.h
 create mode 100644 sysdeps/unix/sysv/linux/x86/pthreaddef.h

diff --git a/nptl/descr.h b/nptl/descr.h
index c83b17b674..fdeb397eab 100644
--- a/nptl/descr.h
+++ b/nptl/descr.h
@@ -65,6 +65,9 @@ struct pthread_unwind_buf
   {
     __jmp_buf jmp_buf;
     int mask_was_saved;
+#ifdef NEED_SAVED_MASK_IN_CANCEL_JMP_BUF
+    __sigset_t saved_mask;
+#endif
   } cancel_jmp_buf[1];
 
   union
diff --git a/sysdeps/unix/sysv/linux/x86/nptl/pthreadP.h b/sysdeps/unix/sysv/linux/x86/nptl/pthreadP.h
new file mode 100644
index 0000000000..8c36ba3a5d
--- /dev/null
+++ b/sysdeps/unix/sysv/linux/x86/nptl/pthreadP.h
@@ -0,0 +1,36 @@
+/* Internal pthread header.  Linux/x86 version.
+   Copyright (C) 2017 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/>.  */
+
+#include_next <nptl/pthreadP.h>
+
+#ifndef _PTHREADP_H_X86
+#define _PTHREADP_H_X86 1
+
+extern struct pthread_unwind_buf ____pthread_unwind_buf_private;
+
+_Static_assert (sizeof (____pthread_unwind_buf_private.cancel_jmp_buf)
+		>= sizeof (struct __jmp_buf_tag),
+		"size of cancel_jmp_buf < sizeof __jmp_buf_tag");
+
+extern __pthread_unwind_buf_t ____pthread_unwind_buf;
+
+_Static_assert (sizeof (____pthread_unwind_buf.__cancel_jmp_buf)
+		>= sizeof (struct __jmp_buf_tag),
+		"size of __cancel_jmp_buf < sizeof __jmp_buf_tag");
+
+#endif
diff --git a/sysdeps/unix/sysv/linux/x86/pthread.h b/sysdeps/unix/sysv/linux/x86/pthread.h
new file mode 100644
index 0000000000..f8991777c1
--- /dev/null
+++ b/sysdeps/unix/sysv/linux/x86/pthread.h
@@ -0,0 +1,1165 @@
+/* Copyright (C) 2017 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/>.  */
+
+#ifndef _PTHREAD_H
+#define _PTHREAD_H	1
+
+#include <features.h>
+#include <endian.h>
+#include <sched.h>
+#include <time.h>
+
+#include <bits/pthreadtypes.h>
+#include <bits/setjmp.h>
+#include <bits/wordsize.h>
+#include <bits/types/struct_timespec.h>
+#include <bits/types/__sigset_t.h>
+
+
+/* Detach state.  */
+enum
+{
+  PTHREAD_CREATE_JOINABLE,
+#define PTHREAD_CREATE_JOINABLE	PTHREAD_CREATE_JOINABLE
+  PTHREAD_CREATE_DETACHED
+#define PTHREAD_CREATE_DETACHED	PTHREAD_CREATE_DETACHED
+};
+
+
+/* Mutex types.  */
+enum
+{
+  PTHREAD_MUTEX_TIMED_NP,
+  PTHREAD_MUTEX_RECURSIVE_NP,
+  PTHREAD_MUTEX_ERRORCHECK_NP,
+  PTHREAD_MUTEX_ADAPTIVE_NP
+#if defined __USE_UNIX98 || defined __USE_XOPEN2K8
+  ,
+  PTHREAD_MUTEX_NORMAL = PTHREAD_MUTEX_TIMED_NP,
+  PTHREAD_MUTEX_RECURSIVE = PTHREAD_MUTEX_RECURSIVE_NP,
+  PTHREAD_MUTEX_ERRORCHECK = PTHREAD_MUTEX_ERRORCHECK_NP,
+  PTHREAD_MUTEX_DEFAULT = PTHREAD_MUTEX_NORMAL
+#endif
+#ifdef __USE_GNU
+  /* For compatibility.  */
+  , PTHREAD_MUTEX_FAST_NP = PTHREAD_MUTEX_TIMED_NP
+#endif
+};
+
+
+#ifdef __USE_XOPEN2K
+/* Robust mutex or not flags.  */
+enum
+{
+  PTHREAD_MUTEX_STALLED,
+  PTHREAD_MUTEX_STALLED_NP = PTHREAD_MUTEX_STALLED,
+  PTHREAD_MUTEX_ROBUST,
+  PTHREAD_MUTEX_ROBUST_NP = PTHREAD_MUTEX_ROBUST
+};
+#endif
+
+
+#if defined __USE_POSIX199506 || defined __USE_UNIX98
+/* Mutex protocols.  */
+enum
+{
+  PTHREAD_PRIO_NONE,
+  PTHREAD_PRIO_INHERIT,
+  PTHREAD_PRIO_PROTECT
+};
+#endif
+
+
+#if __PTHREAD_MUTEX_HAVE_PREV
+# define PTHREAD_MUTEX_INITIALIZER \
+  { { 0, 0, 0, 0, 0, __PTHREAD_SPINS, { 0, 0 } } }
+# ifdef __USE_GNU
+#  define PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP \
+  { { 0, 0, 0, 0, PTHREAD_MUTEX_RECURSIVE_NP, __PTHREAD_SPINS, { 0, 0 } } }
+#  define PTHREAD_ERRORCHECK_MUTEX_INITIALIZER_NP \
+  { { 0, 0, 0, 0, PTHREAD_MUTEX_ERRORCHECK_NP, __PTHREAD_SPINS, { 0, 0 } } }
+#  define PTHREAD_ADAPTIVE_MUTEX_INITIALIZER_NP \
+  { { 0, 0, 0, 0, PTHREAD_MUTEX_ADAPTIVE_NP, __PTHREAD_SPINS, { 0, 0 } } }
+
+# endif
+#else
+# define PTHREAD_MUTEX_INITIALIZER \
+  { { 0, 0, 0, 0, 0, { __PTHREAD_SPINS } } }
+# ifdef __USE_GNU
+#  define PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP \
+  { { 0, 0, 0, PTHREAD_MUTEX_RECURSIVE_NP, 0, { __PTHREAD_SPINS } } }
+#  define PTHREAD_ERRORCHECK_MUTEX_INITIALIZER_NP \
+  { { 0, 0, 0, PTHREAD_MUTEX_ERRORCHECK_NP, 0, { __PTHREAD_SPINS } } }
+#  define PTHREAD_ADAPTIVE_MUTEX_INITIALIZER_NP \
+  { { 0, 0, 0, PTHREAD_MUTEX_ADAPTIVE_NP, 0, { __PTHREAD_SPINS } } }
+
+# endif
+#endif
+
+
+/* Read-write lock types.  */
+#if defined __USE_UNIX98 || defined __USE_XOPEN2K
+enum
+{
+  PTHREAD_RWLOCK_PREFER_READER_NP,
+  PTHREAD_RWLOCK_PREFER_WRITER_NP,
+  PTHREAD_RWLOCK_PREFER_WRITER_NONRECURSIVE_NP,
+  PTHREAD_RWLOCK_DEFAULT_NP = PTHREAD_RWLOCK_PREFER_READER_NP
+};
+
+/* Define __PTHREAD_RWLOCK_INT_FLAGS_SHARED to 1 if pthread_rwlock_t
+   has the shared field.  All 64-bit architectures have the shared field
+   in pthread_rwlock_t.  */
+#ifndef __PTHREAD_RWLOCK_INT_FLAGS_SHARED
+# if __WORDSIZE == 64
+#  define __PTHREAD_RWLOCK_INT_FLAGS_SHARED 1
+# endif
+#endif
+
+/* Read-write lock initializers.  */
+# define PTHREAD_RWLOCK_INITIALIZER \
+  { { 0, 0, 0, 0, 0, 0, 0, 0, __PTHREAD_RWLOCK_ELISION_EXTRA, 0, 0 } }
+# ifdef __USE_GNU
+#  ifdef __PTHREAD_RWLOCK_INT_FLAGS_SHARED
+#   define PTHREAD_RWLOCK_WRITER_NONRECURSIVE_INITIALIZER_NP \
+  { { 0, 0, 0, 0, 0, 0, 0, 0, __PTHREAD_RWLOCK_ELISION_EXTRA, 0,					      \
+	PTHREAD_RWLOCK_PREFER_WRITER_NONRECURSIVE_NP } }
+#  else
+#   if __BYTE_ORDER == __LITTLE_ENDIAN
+#    define PTHREAD_RWLOCK_WRITER_NONRECURSIVE_INITIALIZER_NP \
+  { { 0, 0, 0, 0, 0, 0, PTHREAD_RWLOCK_PREFER_WRITER_NONRECURSIVE_NP, \
+      0, __PTHREAD_RWLOCK_ELISION_EXTRA, 0, 0 } }
+#   else
+#    define PTHREAD_RWLOCK_WRITER_NONRECURSIVE_INITIALIZER_NP \
+  { { 0, 0, 0, 0, 0, 0, 0, 0, 0, PTHREAD_RWLOCK_PREFER_WRITER_NONRECURSIVE_NP,\
+      0 } }
+#   endif
+#  endif
+# endif
+#endif  /* Unix98 or XOpen2K */
+
+
+/* Scheduler inheritance.  */
+enum
+{
+  PTHREAD_INHERIT_SCHED,
+#define PTHREAD_INHERIT_SCHED   PTHREAD_INHERIT_SCHED
+  PTHREAD_EXPLICIT_SCHED
+#define PTHREAD_EXPLICIT_SCHED  PTHREAD_EXPLICIT_SCHED
+};
+
+
+/* Scope handling.  */
+enum
+{
+  PTHREAD_SCOPE_SYSTEM,
+#define PTHREAD_SCOPE_SYSTEM    PTHREAD_SCOPE_SYSTEM
+  PTHREAD_SCOPE_PROCESS
+#define PTHREAD_SCOPE_PROCESS   PTHREAD_SCOPE_PROCESS
+};
+
+
+/* Process shared or private flag.  */
+enum
+{
+  PTHREAD_PROCESS_PRIVATE,
+#define PTHREAD_PROCESS_PRIVATE PTHREAD_PROCESS_PRIVATE
+  PTHREAD_PROCESS_SHARED
+#define PTHREAD_PROCESS_SHARED  PTHREAD_PROCESS_SHARED
+};
+
+
+
+/* Conditional variable handling.  */
+#define PTHREAD_COND_INITIALIZER { { {0}, {0}, {0, 0}, {0, 0}, 0, 0, {0, 0} } }
+
+
+/* Cleanup buffers */
+struct _pthread_cleanup_buffer
+{
+  void (*__routine) (void *);             /* Function to call.  */
+  void *__arg;                            /* Its argument.  */
+  int __canceltype;                       /* Saved cancellation type. */
+  struct _pthread_cleanup_buffer *__prev; /* Chaining of cleanup functions.  */
+};
+
+/* Cancellation */
+enum
+{
+  PTHREAD_CANCEL_ENABLE,
+#define PTHREAD_CANCEL_ENABLE   PTHREAD_CANCEL_ENABLE
+  PTHREAD_CANCEL_DISABLE
+#define PTHREAD_CANCEL_DISABLE  PTHREAD_CANCEL_DISABLE
+};
+enum
+{
+  PTHREAD_CANCEL_DEFERRED,
+#define PTHREAD_CANCEL_DEFERRED	PTHREAD_CANCEL_DEFERRED
+  PTHREAD_CANCEL_ASYNCHRONOUS
+#define PTHREAD_CANCEL_ASYNCHRONOUS	PTHREAD_CANCEL_ASYNCHRONOUS
+};
+#define PTHREAD_CANCELED ((void *) -1)
+
+
+/* Single execution handling.  */
+#define PTHREAD_ONCE_INIT 0
+
+
+#ifdef __USE_XOPEN2K
+/* Value returned by 'pthread_barrier_wait' for one of the threads after
+   the required number of threads have called this function.
+   -1 is distinct from 0 and all errno constants */
+# define PTHREAD_BARRIER_SERIAL_THREAD -1
+#endif
+
+
+__BEGIN_DECLS
+
+/* Create a new thread, starting with execution of START-ROUTINE
+   getting passed ARG.  Creation attributed come from ATTR.  The new
+   handle is stored in *NEWTHREAD.  */
+extern int pthread_create (pthread_t *__restrict __newthread,
+			   const pthread_attr_t *__restrict __attr,
+			   void *(*__start_routine) (void *),
+			   void *__restrict __arg) __THROWNL __nonnull ((1, 3));
+
+/* Terminate calling thread.
+
+   The registered cleanup handlers are called via exception handling
+   so we cannot mark this function with __THROW.*/
+extern void pthread_exit (void *__retval) __attribute__ ((__noreturn__));
+
+/* Make calling thread wait for termination of the thread TH.  The
+   exit status of the thread is stored in *THREAD_RETURN, if THREAD_RETURN
+   is not NULL.
+
+   This function is a cancellation point and therefore not marked with
+   __THROW.  */
+extern int pthread_join (pthread_t __th, void **__thread_return);
+
+#ifdef __USE_GNU
+/* Check whether thread TH has terminated.  If yes return the status of
+   the thread in *THREAD_RETURN, if THREAD_RETURN is not NULL.  */
+extern int pthread_tryjoin_np (pthread_t __th, void **__thread_return) __THROW;
+
+/* Make calling thread wait for termination of the thread TH, but only
+   until TIMEOUT.  The exit status of the thread is stored in
+   *THREAD_RETURN, if THREAD_RETURN is not NULL.
+
+   This function is a cancellation point and therefore not marked with
+   __THROW.  */
+extern int pthread_timedjoin_np (pthread_t __th, void **__thread_return,
+				 const struct timespec *__abstime);
+#endif
+
+/* Indicate that the thread TH is never to be joined with PTHREAD_JOIN.
+   The resources of TH will therefore be freed immediately when it
+   terminates, instead of waiting for another thread to perform PTHREAD_JOIN
+   on it.  */
+extern int pthread_detach (pthread_t __th) __THROW;
+
+
+/* Obtain the identifier of the current thread.  */
+extern pthread_t pthread_self (void) __THROW __attribute__ ((__const__));
+
+/* Compare two thread identifiers.  */
+extern int pthread_equal (pthread_t __thread1, pthread_t __thread2)
+  __THROW __attribute__ ((__const__));
+
+
+/* Thread attribute handling.  */
+
+/* Initialize thread attribute *ATTR with default attributes
+   (detachstate is PTHREAD_JOINABLE, scheduling policy is SCHED_OTHER,
+    no user-provided stack).  */
+extern int pthread_attr_init (pthread_attr_t *__attr) __THROW __nonnull ((1));
+
+/* Destroy thread attribute *ATTR.  */
+extern int pthread_attr_destroy (pthread_attr_t *__attr)
+     __THROW __nonnull ((1));
+
+/* Get detach state attribute.  */
+extern int pthread_attr_getdetachstate (const pthread_attr_t *__attr,
+					int *__detachstate)
+     __THROW __nonnull ((1, 2));
+
+/* Set detach state attribute.  */
+extern int pthread_attr_setdetachstate (pthread_attr_t *__attr,
+					int __detachstate)
+     __THROW __nonnull ((1));
+
+
+/* Get the size of the guard area created for stack overflow protection.  */
+extern int pthread_attr_getguardsize (const pthread_attr_t *__attr,
+				      size_t *__guardsize)
+     __THROW __nonnull ((1, 2));
+
+/* Set the size of the guard area created for stack overflow protection.  */
+extern int pthread_attr_setguardsize (pthread_attr_t *__attr,
+				      size_t __guardsize)
+     __THROW __nonnull ((1));
+
+
+/* Return in *PARAM the scheduling parameters of *ATTR.  */
+extern int pthread_attr_getschedparam (const pthread_attr_t *__restrict __attr,
+				       struct sched_param *__restrict __param)
+     __THROW __nonnull ((1, 2));
+
+/* Set scheduling parameters (priority, etc) in *ATTR according to PARAM.  */
+extern int pthread_attr_setschedparam (pthread_attr_t *__restrict __attr,
+				       const struct sched_param *__restrict
+				       __param) __THROW __nonnull ((1, 2));
+
+/* Return in *POLICY the scheduling policy of *ATTR.  */
+extern int pthread_attr_getschedpolicy (const pthread_attr_t *__restrict
+					__attr, int *__restrict __policy)
+     __THROW __nonnull ((1, 2));
+
+/* Set scheduling policy in *ATTR according to POLICY.  */
+extern int pthread_attr_setschedpolicy (pthread_attr_t *__attr, int __policy)
+     __THROW __nonnull ((1));
+
+/* Return in *INHERIT the scheduling inheritance mode of *ATTR.  */
+extern int pthread_attr_getinheritsched (const pthread_attr_t *__restrict
+					 __attr, int *__restrict __inherit)
+     __THROW __nonnull ((1, 2));
+
+/* Set scheduling inheritance mode in *ATTR according to INHERIT.  */
+extern int pthread_attr_setinheritsched (pthread_attr_t *__attr,
+					 int __inherit)
+     __THROW __nonnull ((1));
+
+
+/* Return in *SCOPE the scheduling contention scope of *ATTR.  */
+extern int pthread_attr_getscope (const pthread_attr_t *__restrict __attr,
+				  int *__restrict __scope)
+     __THROW __nonnull ((1, 2));
+
+/* Set scheduling contention scope in *ATTR according to SCOPE.  */
+extern int pthread_attr_setscope (pthread_attr_t *__attr, int __scope)
+     __THROW __nonnull ((1));
+
+/* Return the previously set address for the stack.  */
+extern int pthread_attr_getstackaddr (const pthread_attr_t *__restrict
+				      __attr, void **__restrict __stackaddr)
+     __THROW __nonnull ((1, 2)) __attribute_deprecated__;
+
+/* Set the starting address of the stack of the thread to be created.
+   Depending on whether the stack grows up or down the value must either
+   be higher or lower than all the address in the memory block.  The
+   minimal size of the block must be PTHREAD_STACK_MIN.  */
+extern int pthread_attr_setstackaddr (pthread_attr_t *__attr,
+				      void *__stackaddr)
+     __THROW __nonnull ((1)) __attribute_deprecated__;
+
+/* Return the currently used minimal stack size.  */
+extern int pthread_attr_getstacksize (const pthread_attr_t *__restrict
+				      __attr, size_t *__restrict __stacksize)
+     __THROW __nonnull ((1, 2));
+
+/* Add information about the minimum stack size needed for the thread
+   to be started.  This size must never be less than PTHREAD_STACK_MIN
+   and must also not exceed the system limits.  */
+extern int pthread_attr_setstacksize (pthread_attr_t *__attr,
+				      size_t __stacksize)
+     __THROW __nonnull ((1));
+
+#ifdef __USE_XOPEN2K
+/* Return the previously set address for the stack.  */
+extern int pthread_attr_getstack (const pthread_attr_t *__restrict __attr,
+				  void **__restrict __stackaddr,
+				  size_t *__restrict __stacksize)
+     __THROW __nonnull ((1, 2, 3));
+
+/* The following two interfaces are intended to replace the last two.  They
+   require setting the address as well as the size since only setting the
+   address will make the implementation on some architectures impossible.  */
+extern int pthread_attr_setstack (pthread_attr_t *__attr, void *__stackaddr,
+				  size_t __stacksize) __THROW __nonnull ((1));
+#endif
+
+#ifdef __USE_GNU
+/* Thread created with attribute ATTR will be limited to run only on
+   the processors represented in CPUSET.  */
+extern int pthread_attr_setaffinity_np (pthread_attr_t *__attr,
+					size_t __cpusetsize,
+					const cpu_set_t *__cpuset)
+     __THROW __nonnull ((1, 3));
+
+/* Get bit set in CPUSET representing the processors threads created with
+   ATTR can run on.  */
+extern int pthread_attr_getaffinity_np (const pthread_attr_t *__attr,
+					size_t __cpusetsize,
+					cpu_set_t *__cpuset)
+     __THROW __nonnull ((1, 3));
+
+/* Get the default attributes used by pthread_create in this process.  */
+extern int pthread_getattr_default_np (pthread_attr_t *__attr)
+     __THROW __nonnull ((1));
+
+/* Set the default attributes to be used by pthread_create in this
+   process.  */
+extern int pthread_setattr_default_np (const pthread_attr_t *__attr)
+     __THROW __nonnull ((1));
+
+/* Initialize thread attribute *ATTR with attributes corresponding to the
+   already running thread TH.  It shall be called on uninitialized ATTR
+   and destroyed with pthread_attr_destroy when no longer needed.  */
+extern int pthread_getattr_np (pthread_t __th, pthread_attr_t *__attr)
+     __THROW __nonnull ((2));
+#endif
+
+
+/* Functions for scheduling control.  */
+
+/* Set the scheduling parameters for TARGET_THREAD according to POLICY
+   and *PARAM.  */
+extern int pthread_setschedparam (pthread_t __target_thread, int __policy,
+				  const struct sched_param *__param)
+     __THROW __nonnull ((3));
+
+/* Return in *POLICY and *PARAM the scheduling parameters for TARGET_THREAD. */
+extern int pthread_getschedparam (pthread_t __target_thread,
+				  int *__restrict __policy,
+				  struct sched_param *__restrict __param)
+     __THROW __nonnull ((2, 3));
+
+/* Set the scheduling priority for TARGET_THREAD.  */
+extern int pthread_setschedprio (pthread_t __target_thread, int __prio)
+     __THROW;
+
+
+#ifdef __USE_GNU
+/* Get thread name visible in the kernel and its interfaces.  */
+extern int pthread_getname_np (pthread_t __target_thread, char *__buf,
+			       size_t __buflen)
+     __THROW __nonnull ((2));
+
+/* Set thread name visible in the kernel and its interfaces.  */
+extern int pthread_setname_np (pthread_t __target_thread, const char *__name)
+     __THROW __nonnull ((2));
+#endif
+
+
+#ifdef __USE_UNIX98
+/* Determine level of concurrency.  */
+extern int pthread_getconcurrency (void) __THROW;
+
+/* Set new concurrency level to LEVEL.  */
+extern int pthread_setconcurrency (int __level) __THROW;
+#endif
+
+#ifdef __USE_GNU
+/* Yield the processor to another thread or process.
+   This function is similar to the POSIX `sched_yield' function but
+   might be differently implemented in the case of a m-on-n thread
+   implementation.  */
+extern int pthread_yield (void) __THROW;
+
+
+/* Limit specified thread TH to run only on the processors represented
+   in CPUSET.  */
+extern int pthread_setaffinity_np (pthread_t __th, size_t __cpusetsize,
+				   const cpu_set_t *__cpuset)
+     __THROW __nonnull ((3));
+
+/* Get bit set in CPUSET representing the processors TH can run on.  */
+extern int pthread_getaffinity_np (pthread_t __th, size_t __cpusetsize,
+				   cpu_set_t *__cpuset)
+     __THROW __nonnull ((3));
+#endif
+
+
+/* Functions for handling initialization.  */
+
+/* Guarantee that the initialization function INIT_ROUTINE will be called
+   only once, even if pthread_once is executed several times with the
+   same ONCE_CONTROL argument. ONCE_CONTROL must point to a static or
+   extern variable initialized to PTHREAD_ONCE_INIT.
+
+   The initialization functions might throw exception which is why
+   this function is not marked with __THROW.  */
+extern int pthread_once (pthread_once_t *__once_control,
+			 void (*__init_routine) (void)) __nonnull ((1, 2));
+
+
+/* Functions for handling cancellation.
+
+   Note that these functions are explicitly not marked to not throw an
+   exception in C++ code.  If cancellation is implemented by unwinding
+   this is necessary to have the compiler generate the unwind information.  */
+
+/* Set cancelability state of current thread to STATE, returning old
+   state in *OLDSTATE if OLDSTATE is not NULL.  */
+extern int pthread_setcancelstate (int __state, int *__oldstate);
+
+/* Set cancellation state of current thread to TYPE, returning the old
+   type in *OLDTYPE if OLDTYPE is not NULL.  */
+extern int pthread_setcanceltype (int __type, int *__oldtype);
+
+/* Cancel THREAD immediately or at the next possibility.  */
+extern int pthread_cancel (pthread_t __th);
+
+/* Test for pending cancellation for the current thread and terminate
+   the thread as per pthread_exit(PTHREAD_CANCELED) if it has been
+   cancelled.  */
+extern void pthread_testcancel (void);
+
+
+/* Cancellation handling with integration into exception handling.  */
+
+typedef struct
+{
+  /* This must match struct __jmp_buf_tag in <setjmp.h>.  */
+  struct
+  {
+    __jmp_buf __cancel_jmp_buf;
+    int __mask_was_saved;
+    __sigset_t __saved_mask;
+  } __cancel_jmp_buf[1];
+  void *__pad[4];
+} __pthread_unwind_buf_t __attribute__ ((__aligned__));
+
+/* No special attributes by default.  */
+#ifndef __cleanup_fct_attribute
+# define __cleanup_fct_attribute
+#endif
+
+
+/* Structure to hold the cleanup handler information.  */
+struct __pthread_cleanup_frame
+{
+  void (*__cancel_routine) (void *);
+  void *__cancel_arg;
+  int __do_it;
+  int __cancel_type;
+};
+
+#if defined __GNUC__ && defined __EXCEPTIONS
+# ifdef __cplusplus
+/* Class to handle cancellation handler invocation.  */
+class __pthread_cleanup_class
+{
+  void (*__cancel_routine) (void *);
+  void *__cancel_arg;
+  int __do_it;
+  int __cancel_type;
+
+ public:
+  __pthread_cleanup_class (void (*__fct) (void *), void *__arg)
+    : __cancel_routine (__fct), __cancel_arg (__arg), __do_it (1) { }
+  ~__pthread_cleanup_class () { if (__do_it) __cancel_routine (__cancel_arg); }
+  void __setdoit (int __newval) { __do_it = __newval; }
+  void __defer () { pthread_setcanceltype (PTHREAD_CANCEL_DEFERRED,
+					   &__cancel_type); }
+  void __restore () const { pthread_setcanceltype (__cancel_type, 0); }
+};
+
+/* Install a cleanup handler: ROUTINE will be called with arguments ARG
+   when the thread is canceled or calls pthread_exit.  ROUTINE will also
+   be called with arguments ARG when the matching pthread_cleanup_pop
+   is executed with non-zero EXECUTE argument.
+
+   pthread_cleanup_push and pthread_cleanup_pop are macros and must always
+   be used in matching pairs at the same nesting level of braces.  */
+#  define pthread_cleanup_push(routine, arg) \
+  do {									      \
+    __pthread_cleanup_class __clframe (routine, arg)
+
+/* Remove a cleanup handler installed by the matching pthread_cleanup_push.
+   If EXECUTE is non-zero, the handler function is called. */
+#  define pthread_cleanup_pop(execute) \
+    __clframe.__setdoit (execute);					      \
+  } while (0)
+
+#  ifdef __USE_GNU
+/* Install a cleanup handler as pthread_cleanup_push does, but also
+   saves the current cancellation type and sets it to deferred
+   cancellation.  */
+#   define pthread_cleanup_push_defer_np(routine, arg) \
+  do {									      \
+    __pthread_cleanup_class __clframe (routine, arg);			      \
+    __clframe.__defer ()
+
+/* Remove a cleanup handler as pthread_cleanup_pop does, but also
+   restores the cancellation type that was in effect when the matching
+   pthread_cleanup_push_defer was called.  */
+#   define pthread_cleanup_pop_restore_np(execute) \
+    __clframe.__restore ();						      \
+    __clframe.__setdoit (execute);					      \
+  } while (0)
+#  endif
+# else
+/* Function called to call the cleanup handler.  As an extern inline
+   function the compiler is free to decide inlining the change when
+   needed or fall back on the copy which must exist somewhere
+   else.  */
+__extern_inline void
+__pthread_cleanup_routine (struct __pthread_cleanup_frame *__frame)
+{
+  if (__frame->__do_it)
+    __frame->__cancel_routine (__frame->__cancel_arg);
+}
+
+/* Install a cleanup handler: ROUTINE will be called with arguments ARG
+   when the thread is canceled or calls pthread_exit.  ROUTINE will also
+   be called with arguments ARG when the matching pthread_cleanup_pop
+   is executed with non-zero EXECUTE argument.
+
+   pthread_cleanup_push and pthread_cleanup_pop are macros and must always
+   be used in matching pairs at the same nesting level of braces.  */
+#  define pthread_cleanup_push(routine, arg) \
+  do {									      \
+    struct __pthread_cleanup_frame __clframe				      \
+      __attribute__ ((__cleanup__ (__pthread_cleanup_routine)))		      \
+      = { .__cancel_routine = (routine), .__cancel_arg = (arg),	 	      \
+	  .__do_it = 1 };
+
+/* Remove a cleanup handler installed by the matching pthread_cleanup_push.
+   If EXECUTE is non-zero, the handler function is called. */
+#  define pthread_cleanup_pop(execute) \
+    __clframe.__do_it = (execute);					      \
+  } while (0)
+
+#  ifdef __USE_GNU
+/* Install a cleanup handler as pthread_cleanup_push does, but also
+   saves the current cancellation type and sets it to deferred
+   cancellation.  */
+#   define pthread_cleanup_push_defer_np(routine, arg) \
+  do {									      \
+    struct __pthread_cleanup_frame __clframe				      \
+      __attribute__ ((__cleanup__ (__pthread_cleanup_routine)))		      \
+      = { .__cancel_routine = (routine), .__cancel_arg = (arg),		      \
+	  .__do_it = 1 };						      \
+    (void) pthread_setcanceltype (PTHREAD_CANCEL_DEFERRED,		      \
+				  &__clframe.__cancel_type)
+
+/* Remove a cleanup handler as pthread_cleanup_pop does, but also
+   restores the cancellation type that was in effect when the matching
+   pthread_cleanup_push_defer was called.  */
+#   define pthread_cleanup_pop_restore_np(execute) \
+    (void) pthread_setcanceltype (__clframe.__cancel_type, NULL);	      \
+    __clframe.__do_it = (execute);					      \
+  } while (0)
+#  endif
+# endif
+#else
+/* Install a cleanup handler: ROUTINE will be called with arguments ARG
+   when the thread is canceled or calls pthread_exit.  ROUTINE will also
+   be called with arguments ARG when the matching pthread_cleanup_pop
+   is executed with non-zero EXECUTE argument.
+
+   pthread_cleanup_push and pthread_cleanup_pop are macros and must always
+   be used in matching pairs at the same nesting level of braces.  */
+# define pthread_cleanup_push(routine, arg) \
+  do {									      \
+    __pthread_unwind_buf_t __cancel_buf;				      \
+    void (*__cancel_routine) (void *) = (routine);			      \
+    void *__cancel_arg = (arg);						      \
+    int __not_first_call = __sigsetjmp ((struct __jmp_buf_tag *) (void *)     \
+					__cancel_buf.__cancel_jmp_buf, 0);    \
+    if (__glibc_unlikely (__not_first_call))				      \
+      {									      \
+	__cancel_routine (__cancel_arg);				      \
+	__pthread_unwind_next (&__cancel_buf);				      \
+	/* NOTREACHED */						      \
+      }									      \
+									      \
+    __pthread_register_cancel (&__cancel_buf);				      \
+    do {
+extern void __pthread_register_cancel (__pthread_unwind_buf_t *__buf)
+     __cleanup_fct_attribute;
+
+/* Remove a cleanup handler installed by the matching pthread_cleanup_push.
+   If EXECUTE is non-zero, the handler function is called. */
+# define pthread_cleanup_pop(execute) \
+      do { } while (0);/* Empty to allow label before pthread_cleanup_pop.  */\
+    } while (0);							      \
+    __pthread_unregister_cancel (&__cancel_buf);			      \
+    if (execute)							      \
+      __cancel_routine (__cancel_arg);					      \
+  } while (0)
+extern void __pthread_unregister_cancel (__pthread_unwind_buf_t *__buf)
+  __cleanup_fct_attribute;
+
+# ifdef __USE_GNU
+/* Install a cleanup handler as pthread_cleanup_push does, but also
+   saves the current cancellation type and sets it to deferred
+   cancellation.  */
+#  define pthread_cleanup_push_defer_np(routine, arg) \
+  do {									      \
+    __pthread_unwind_buf_t __cancel_buf;				      \
+    void (*__cancel_routine) (void *) = (routine);			      \
+    void *__cancel_arg = (arg);						      \
+    int __not_first_call = __sigsetjmp ((struct __jmp_buf_tag *) (void *)     \
+					__cancel_buf.__cancel_jmp_buf, 0);    \
+    if (__glibc_unlikely (__not_first_call))				      \
+      {									      \
+	__cancel_routine (__cancel_arg);				      \
+	__pthread_unwind_next (&__cancel_buf);				      \
+	/* NOTREACHED */						      \
+      }									      \
+									      \
+    __pthread_register_cancel_defer (&__cancel_buf);			      \
+    do {
+extern void __pthread_register_cancel_defer (__pthread_unwind_buf_t *__buf)
+     __cleanup_fct_attribute;
+
+/* Remove a cleanup handler as pthread_cleanup_pop does, but also
+   restores the cancellation type that was in effect when the matching
+   pthread_cleanup_push_defer was called.  */
+#  define pthread_cleanup_pop_restore_np(execute) \
+      do { } while (0);/* Empty to allow label before pthread_cleanup_pop.  */\
+    } while (0);							      \
+    __pthread_unregister_cancel_restore (&__cancel_buf);		      \
+    if (execute)							      \
+      __cancel_routine (__cancel_arg);					      \
+  } while (0)
+extern void __pthread_unregister_cancel_restore (__pthread_unwind_buf_t *__buf)
+  __cleanup_fct_attribute;
+# endif
+
+/* Internal interface to initiate cleanup.  */
+extern void __pthread_unwind_next (__pthread_unwind_buf_t *__buf)
+     __cleanup_fct_attribute __attribute__ ((__noreturn__))
+# ifndef SHARED
+     __attribute__ ((__weak__))
+# endif
+     ;
+#endif
+
+/* Function used in the macros.  */
+struct __jmp_buf_tag;
+extern int __sigsetjmp (struct __jmp_buf_tag *__env, int __savemask) __THROWNL;
+
+
+/* Mutex handling.  */
+
+/* Initialize a mutex.  */
+extern int pthread_mutex_init (pthread_mutex_t *__mutex,
+			       const pthread_mutexattr_t *__mutexattr)
+     __THROW __nonnull ((1));
+
+/* Destroy a mutex.  */
+extern int pthread_mutex_destroy (pthread_mutex_t *__mutex)
+     __THROW __nonnull ((1));
+
+/* Try locking a mutex.  */
+extern int pthread_mutex_trylock (pthread_mutex_t *__mutex)
+     __THROWNL __nonnull ((1));
+
+/* Lock a mutex.  */
+extern int pthread_mutex_lock (pthread_mutex_t *__mutex)
+     __THROWNL __nonnull ((1));
+
+#ifdef __USE_XOPEN2K
+/* Wait until lock becomes available, or specified time passes. */
+extern int pthread_mutex_timedlock (pthread_mutex_t *__restrict __mutex,
+				    const struct timespec *__restrict
+				    __abstime) __THROWNL __nonnull ((1, 2));
+#endif
+
+/* Unlock a mutex.  */
+extern int pthread_mutex_unlock (pthread_mutex_t *__mutex)
+     __THROWNL __nonnull ((1));
+
+
+/* Get the priority ceiling of MUTEX.  */
+extern int pthread_mutex_getprioceiling (const pthread_mutex_t *
+					 __restrict __mutex,
+					 int *__restrict __prioceiling)
+     __THROW __nonnull ((1, 2));
+
+/* Set the priority ceiling of MUTEX to PRIOCEILING, return old
+   priority ceiling value in *OLD_CEILING.  */
+extern int pthread_mutex_setprioceiling (pthread_mutex_t *__restrict __mutex,
+					 int __prioceiling,
+					 int *__restrict __old_ceiling)
+     __THROW __nonnull ((1, 3));
+
+
+#ifdef __USE_XOPEN2K8
+/* Declare the state protected by MUTEX as consistent.  */
+extern int pthread_mutex_consistent (pthread_mutex_t *__mutex)
+     __THROW __nonnull ((1));
+# ifdef __USE_GNU
+extern int pthread_mutex_consistent_np (pthread_mutex_t *__mutex)
+     __THROW __nonnull ((1));
+# endif
+#endif
+
+
+/* Functions for handling mutex attributes.  */
+
+/* Initialize mutex attribute object ATTR with default attributes
+   (kind is PTHREAD_MUTEX_TIMED_NP).  */
+extern int pthread_mutexattr_init (pthread_mutexattr_t *__attr)
+     __THROW __nonnull ((1));
+
+/* Destroy mutex attribute object ATTR.  */
+extern int pthread_mutexattr_destroy (pthread_mutexattr_t *__attr)
+     __THROW __nonnull ((1));
+
+/* Get the process-shared flag of the mutex attribute ATTR.  */
+extern int pthread_mutexattr_getpshared (const pthread_mutexattr_t *
+					 __restrict __attr,
+					 int *__restrict __pshared)
+     __THROW __nonnull ((1, 2));
+
+/* Set the process-shared flag of the mutex attribute ATTR.  */
+extern int pthread_mutexattr_setpshared (pthread_mutexattr_t *__attr,
+					 int __pshared)
+     __THROW __nonnull ((1));
+
+#if defined __USE_UNIX98 || defined __USE_XOPEN2K8
+/* Return in *KIND the mutex kind attribute in *ATTR.  */
+extern int pthread_mutexattr_gettype (const pthread_mutexattr_t *__restrict
+				      __attr, int *__restrict __kind)
+     __THROW __nonnull ((1, 2));
+
+/* Set the mutex kind attribute in *ATTR to KIND (either PTHREAD_MUTEX_NORMAL,
+   PTHREAD_MUTEX_RECURSIVE, PTHREAD_MUTEX_ERRORCHECK, or
+   PTHREAD_MUTEX_DEFAULT).  */
+extern int pthread_mutexattr_settype (pthread_mutexattr_t *__attr, int __kind)
+     __THROW __nonnull ((1));
+#endif
+
+/* Return in *PROTOCOL the mutex protocol attribute in *ATTR.  */
+extern int pthread_mutexattr_getprotocol (const pthread_mutexattr_t *
+					  __restrict __attr,
+					  int *__restrict __protocol)
+     __THROW __nonnull ((1, 2));
+
+/* Set the mutex protocol attribute in *ATTR to PROTOCOL (either
+   PTHREAD_PRIO_NONE, PTHREAD_PRIO_INHERIT, or PTHREAD_PRIO_PROTECT).  */
+extern int pthread_mutexattr_setprotocol (pthread_mutexattr_t *__attr,
+					  int __protocol)
+     __THROW __nonnull ((1));
+
+/* Return in *PRIOCEILING the mutex prioceiling attribute in *ATTR.  */
+extern int pthread_mutexattr_getprioceiling (const pthread_mutexattr_t *
+					     __restrict __attr,
+					     int *__restrict __prioceiling)
+     __THROW __nonnull ((1, 2));
+
+/* Set the mutex prioceiling attribute in *ATTR to PRIOCEILING.  */
+extern int pthread_mutexattr_setprioceiling (pthread_mutexattr_t *__attr,
+					     int __prioceiling)
+     __THROW __nonnull ((1));
+
+#ifdef __USE_XOPEN2K
+/* Get the robustness flag of the mutex attribute ATTR.  */
+extern int pthread_mutexattr_getrobust (const pthread_mutexattr_t *__attr,
+					int *__robustness)
+     __THROW __nonnull ((1, 2));
+# ifdef __USE_GNU
+extern int pthread_mutexattr_getrobust_np (const pthread_mutexattr_t *__attr,
+					   int *__robustness)
+     __THROW __nonnull ((1, 2));
+# endif
+
+/* Set the robustness flag of the mutex attribute ATTR.  */
+extern int pthread_mutexattr_setrobust (pthread_mutexattr_t *__attr,
+					int __robustness)
+     __THROW __nonnull ((1));
+# ifdef __USE_GNU
+extern int pthread_mutexattr_setrobust_np (pthread_mutexattr_t *__attr,
+					   int __robustness)
+     __THROW __nonnull ((1));
+# endif
+#endif
+
+
+#if defined __USE_UNIX98 || defined __USE_XOPEN2K
+/* Functions for handling read-write locks.  */
+
+/* Initialize read-write lock RWLOCK using attributes ATTR, or use
+   the default values if later is NULL.  */
+extern int pthread_rwlock_init (pthread_rwlock_t *__restrict __rwlock,
+				const pthread_rwlockattr_t *__restrict
+				__attr) __THROW __nonnull ((1));
+
+/* Destroy read-write lock RWLOCK.  */
+extern int pthread_rwlock_destroy (pthread_rwlock_t *__rwlock)
+     __THROW __nonnull ((1));
+
+/* Acquire read lock for RWLOCK.  */
+extern int pthread_rwlock_rdlock (pthread_rwlock_t *__rwlock)
+     __THROWNL __nonnull ((1));
+
+/* Try to acquire read lock for RWLOCK.  */
+extern int pthread_rwlock_tryrdlock (pthread_rwlock_t *__rwlock)
+  __THROWNL __nonnull ((1));
+
+# ifdef __USE_XOPEN2K
+/* Try to acquire read lock for RWLOCK or return after specfied time.  */
+extern int pthread_rwlock_timedrdlock (pthread_rwlock_t *__restrict __rwlock,
+				       const struct timespec *__restrict
+				       __abstime) __THROWNL __nonnull ((1, 2));
+# endif
+
+/* Acquire write lock for RWLOCK.  */
+extern int pthread_rwlock_wrlock (pthread_rwlock_t *__rwlock)
+     __THROWNL __nonnull ((1));
+
+/* Try to acquire write lock for RWLOCK.  */
+extern int pthread_rwlock_trywrlock (pthread_rwlock_t *__rwlock)
+     __THROWNL __nonnull ((1));
+
+# ifdef __USE_XOPEN2K
+/* Try to acquire write lock for RWLOCK or return after specfied time.  */
+extern int pthread_rwlock_timedwrlock (pthread_rwlock_t *__restrict __rwlock,
+				       const struct timespec *__restrict
+				       __abstime) __THROWNL __nonnull ((1, 2));
+# endif
+
+/* Unlock RWLOCK.  */
+extern int pthread_rwlock_unlock (pthread_rwlock_t *__rwlock)
+     __THROWNL __nonnull ((1));
+
+
+/* Functions for handling read-write lock attributes.  */
+
+/* Initialize attribute object ATTR with default values.  */
+extern int pthread_rwlockattr_init (pthread_rwlockattr_t *__attr)
+     __THROW __nonnull ((1));
+
+/* Destroy attribute object ATTR.  */
+extern int pthread_rwlockattr_destroy (pthread_rwlockattr_t *__attr)
+     __THROW __nonnull ((1));
+
+/* Return current setting of process-shared attribute of ATTR in PSHARED.  */
+extern int pthread_rwlockattr_getpshared (const pthread_rwlockattr_t *
+					  __restrict __attr,
+					  int *__restrict __pshared)
+     __THROW __nonnull ((1, 2));
+
+/* Set process-shared attribute of ATTR to PSHARED.  */
+extern int pthread_rwlockattr_setpshared (pthread_rwlockattr_t *__attr,
+					  int __pshared)
+     __THROW __nonnull ((1));
+
+/* Return current setting of reader/writer preference.  */
+extern int pthread_rwlockattr_getkind_np (const pthread_rwlockattr_t *
+					  __restrict __attr,
+					  int *__restrict __pref)
+     __THROW __nonnull ((1, 2));
+
+/* Set reader/write preference.  */
+extern int pthread_rwlockattr_setkind_np (pthread_rwlockattr_t *__attr,
+					  int __pref) __THROW __nonnull ((1));
+#endif
+
+
+/* Functions for handling conditional variables.  */
+
+/* Initialize condition variable COND using attributes ATTR, or use
+   the default values if later is NULL.  */
+extern int pthread_cond_init (pthread_cond_t *__restrict __cond,
+			      const pthread_condattr_t *__restrict __cond_attr)
+     __THROW __nonnull ((1));
+
+/* Destroy condition variable COND.  */
+extern int pthread_cond_destroy (pthread_cond_t *__cond)
+     __THROW __nonnull ((1));
+
+/* Wake up one thread waiting for condition variable COND.  */
+extern int pthread_cond_signal (pthread_cond_t *__cond)
+     __THROWNL __nonnull ((1));
+
+/* Wake up all threads waiting for condition variables COND.  */
+extern int pthread_cond_broadcast (pthread_cond_t *__cond)
+     __THROWNL __nonnull ((1));
+
+/* Wait for condition variable COND to be signaled or broadcast.
+   MUTEX is assumed to be locked before.
+
+   This function is a cancellation point and therefore not marked with
+   __THROW.  */
+extern int pthread_cond_wait (pthread_cond_t *__restrict __cond,
+			      pthread_mutex_t *__restrict __mutex)
+     __nonnull ((1, 2));
+
+/* Wait for condition variable COND to be signaled or broadcast until
+   ABSTIME.  MUTEX is assumed to be locked before.  ABSTIME is an
+   absolute time specification; zero is the beginning of the epoch
+   (00:00:00 GMT, January 1, 1970).
+
+   This function is a cancellation point and therefore not marked with
+   __THROW.  */
+extern int pthread_cond_timedwait (pthread_cond_t *__restrict __cond,
+				   pthread_mutex_t *__restrict __mutex,
+				   const struct timespec *__restrict __abstime)
+     __nonnull ((1, 2, 3));
+
+/* Functions for handling condition variable attributes.  */
+
+/* Initialize condition variable attribute ATTR.  */
+extern int pthread_condattr_init (pthread_condattr_t *__attr)
+     __THROW __nonnull ((1));
+
+/* Destroy condition variable attribute ATTR.  */
+extern int pthread_condattr_destroy (pthread_condattr_t *__attr)
+     __THROW __nonnull ((1));
+
+/* Get the process-shared flag of the condition variable attribute ATTR.  */
+extern int pthread_condattr_getpshared (const pthread_condattr_t *
+					__restrict __attr,
+					int *__restrict __pshared)
+     __THROW __nonnull ((1, 2));
+
+/* Set the process-shared flag of the condition variable attribute ATTR.  */
+extern int pthread_condattr_setpshared (pthread_condattr_t *__attr,
+					int __pshared) __THROW __nonnull ((1));
+
+#ifdef __USE_XOPEN2K
+/* Get the clock selected for the condition variable attribute ATTR.  */
+extern int pthread_condattr_getclock (const pthread_condattr_t *
+				      __restrict __attr,
+				      __clockid_t *__restrict __clock_id)
+     __THROW __nonnull ((1, 2));
+
+/* Set the clock selected for the condition variable attribute ATTR.  */
+extern int pthread_condattr_setclock (pthread_condattr_t *__attr,
+				      __clockid_t __clock_id)
+     __THROW __nonnull ((1));
+#endif
+
+
+#ifdef __USE_XOPEN2K
+/* Functions to handle spinlocks.  */
+
+/* Initialize the spinlock LOCK.  If PSHARED is nonzero the spinlock can
+   be shared between different processes.  */
+extern int pthread_spin_init (pthread_spinlock_t *__lock, int __pshared)
+     __THROW __nonnull ((1));
+
+/* Destroy the spinlock LOCK.  */
+extern int pthread_spin_destroy (pthread_spinlock_t *__lock)
+     __THROW __nonnull ((1));
+
+/* Wait until spinlock LOCK is retrieved.  */
+extern int pthread_spin_lock (pthread_spinlock_t *__lock)
+     __THROWNL __nonnull ((1));
+
+/* Try to lock spinlock LOCK.  */
+extern int pthread_spin_trylock (pthread_spinlock_t *__lock)
+     __THROWNL __nonnull ((1));
+
+/* Release spinlock LOCK.  */
+extern int pthread_spin_unlock (pthread_spinlock_t *__lock)
+     __THROWNL __nonnull ((1));
+
+
+/* Functions to handle barriers.  */
+
+/* Initialize BARRIER with the attributes in ATTR.  The barrier is
+   opened when COUNT waiters arrived.  */
+extern int pthread_barrier_init (pthread_barrier_t *__restrict __barrier,
+				 const pthread_barrierattr_t *__restrict
+				 __attr, unsigned int __count)
+     __THROW __nonnull ((1));
+
+/* Destroy a previously dynamically initialized barrier BARRIER.  */
+extern int pthread_barrier_destroy (pthread_barrier_t *__barrier)
+     __THROW __nonnull ((1));
+
+/* Wait on barrier BARRIER.  */
+extern int pthread_barrier_wait (pthread_barrier_t *__barrier)
+     __THROWNL __nonnull ((1));
+
+
+/* Initialize barrier attribute ATTR.  */
+extern int pthread_barrierattr_init (pthread_barrierattr_t *__attr)
+     __THROW __nonnull ((1));
+
+/* Destroy previously dynamically initialized barrier attribute ATTR.  */
+extern int pthread_barrierattr_destroy (pthread_barrierattr_t *__attr)
+     __THROW __nonnull ((1));
+
+/* Get the process-shared flag of the barrier attribute ATTR.  */
+extern int pthread_barrierattr_getpshared (const pthread_barrierattr_t *
+					   __restrict __attr,
+					   int *__restrict __pshared)
+     __THROW __nonnull ((1, 2));
+
+/* Set the process-shared flag of the barrier attribute ATTR.  */
+extern int pthread_barrierattr_setpshared (pthread_barrierattr_t *__attr,
+					   int __pshared)
+     __THROW __nonnull ((1));
+#endif
+
+
+/* Functions for handling thread-specific data.  */
+
+/* Create a key value identifying a location in the thread-specific
+   data area.  Each thread maintains a distinct thread-specific data
+   area.  DESTR_FUNCTION, if non-NULL, is called with the value
+   associated to that key when the key is destroyed.
+   DESTR_FUNCTION is not called if the value associated is NULL when
+   the key is destroyed.  */
+extern int pthread_key_create (pthread_key_t *__key,
+			       void (*__destr_function) (void *))
+     __THROW __nonnull ((1));
+
+/* Destroy KEY.  */
+extern int pthread_key_delete (pthread_key_t __key) __THROW;
+
+/* Return current value of the thread-specific data slot identified by KEY.  */
+extern void *pthread_getspecific (pthread_key_t __key) __THROW;
+
+/* Store POINTER in the thread-specific data slot identified by KEY. */
+extern int pthread_setspecific (pthread_key_t __key,
+				const void *__pointer) __THROW ;
+
+
+#ifdef __USE_XOPEN2K
+/* Get ID of CPU-time clock for thread THREAD_ID.  */
+extern int pthread_getcpuclockid (pthread_t __thread_id,
+				  __clockid_t *__clock_id)
+     __THROW __nonnull ((2));
+#endif
+
+
+/* Install handlers to be called when a new process is created with FORK.
+   The PREPARE handler is called in the parent process just before performing
+   FORK. The PARENT handler is called in the parent process just after FORK.
+   The CHILD handler is called in the child process.  Each of the three
+   handlers can be NULL, meaning that no handler needs to be called at that
+   point.
+   PTHREAD_ATFORK can be called several times, in which case the PREPARE
+   handlers are called in LIFO order (last added with PTHREAD_ATFORK,
+   first called before FORK), and the PARENT and CHILD handlers are called
+   in FIFO (first added, first called).  */
+
+extern int pthread_atfork (void (*__prepare) (void),
+			   void (*__parent) (void),
+			   void (*__child) (void)) __THROW;
+
+
+#ifdef __USE_EXTERN_INLINES
+/* Optimizations.  */
+__extern_inline int
+__NTH (pthread_equal (pthread_t __thread1, pthread_t __thread2))
+{
+  return __thread1 == __thread2;
+}
+#endif
+
+__END_DECLS
+
+#endif	/* pthread.h */
diff --git a/sysdeps/unix/sysv/linux/x86/pthreaddef.h b/sysdeps/unix/sysv/linux/x86/pthreaddef.h
new file mode 100644
index 0000000000..89d19d60a1
--- /dev/null
+++ b/sysdeps/unix/sysv/linux/x86/pthreaddef.h
@@ -0,0 +1,22 @@
+/* Pthread macros.  Linux/x86 version.
+   Copyright (C) 2017 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/>.  */
+
+#include_next <pthreaddef.h>
+
+/* Need saved_mask in cancel_jmp_buf.  */
+#define NEED_SAVED_MASK_IN_CANCEL_JMP_BUF 1
-- 
2.14.3

^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: [PATCH 1/2] Linux/x86: Update cancel_jmp_buf to match __jmp_buf_tag [BZ #22563]
  2017-12-07 17:41 [PATCH 1/2] Linux/x86: Update cancel_jmp_buf to match __jmp_buf_tag [BZ #22563] H.J. Lu
@ 2017-12-07 17:58 ` Joseph Myers
  2017-12-07 18:37 ` Florian Weimer
  1 sibling, 0 replies; 63+ messages in thread
From: Joseph Myers @ 2017-12-07 17:58 UTC (permalink / raw)
  To: H.J. Lu; +Cc: GNU C Library

On Thu, 7 Dec 2017, H.J. Lu wrote:

> On x86, padding in struct __jmp_buf_tag is used for shadow stack pointer
> to support shadow stack in Intel Control-flow Enforcemen Technology.
> Since the cancel_jmp_buf array is passed to setjmp and longjmp by
> casting it to pointer to struct __jmp_buf_tag, it should be as large
> as struct __jmp_buf_tag.  This patch adds pthread.h, pthreaddef.h and
> pthreadP.h for Linux/x86 to define a new cancel_jmp_buf to match
> struct __jmp_buf_tag.

Duplicating the installed pthread.h is a bad idea (in general, we should 
avoid having architecture-specific variants of installed headers as much 
as possible, and, especially, define APIs in architecture-independent 
headers and limit architecture-specific variants to as few constants or 
structures as possible, those going in bits/ headers that at least people 
expect to have multiple variants).

Thus, we should aim to eliminate the hppa-specific variant of pthread.h by 
creating a bits/ header that has the minimum information required to 
encapsulate the hppa variations (or putting such information in an 
existing bits/ header, if appropriate), and likewise for whatever the 
differences are in your x86 variant.  We should certainly not create a new 
x86 variant of the whole of pthread.h.

-- 
Joseph S. Myers
joseph@codesourcery.com

^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: [PATCH 1/2] Linux/x86: Update cancel_jmp_buf to match __jmp_buf_tag [BZ #22563]
  2017-12-07 17:41 [PATCH 1/2] Linux/x86: Update cancel_jmp_buf to match __jmp_buf_tag [BZ #22563] H.J. Lu
  2017-12-07 17:58 ` Joseph Myers
@ 2017-12-07 18:37 ` Florian Weimer
  2017-12-07 18:59   ` H.J. Lu
  1 sibling, 1 reply; 63+ messages in thread
From: Florian Weimer @ 2017-12-07 18:37 UTC (permalink / raw)
  To: H.J. Lu, GNU C Library

On 12/07/2017 06:40 PM, H.J. Lu wrote:
> On x86, padding in struct __jmp_buf_tag is used for shadow stack pointer
> to support shadow stack in Intel Control-flow Enforcemen Technology.
> Since the cancel_jmp_buf array is passed to setjmp and longjmp by
> casting it to pointer to struct __jmp_buf_tag, it should be as large
> as struct __jmp_buf_tag.  This patch adds pthread.h, pthreaddef.h and
> pthreadP.h for Linux/x86 to define a new cancel_jmp_buf to match
> struct __jmp_buf_tag.

This seems the wrong thing to do.

I don't think cancellation needs the shadow stack because none of the 
functions on the existing stack return during cancellation processing.

Furthermore, SJLJ-style cancellation appears to defeat CET anyway, so 
I'm puzzled why aren't trying to get rid of this type of cancellation 
implementation instead because it looks like a fairly significant 
weakness (similar to SEH on Windows).

If you want to preserve SJLJ-style cancellation as-is, 
__pthread_unwind_buf_t has sufficient padding, and you could simply use 
that.

Thanks,
Florian

^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: [PATCH 1/2] Linux/x86: Update cancel_jmp_buf to match __jmp_buf_tag [BZ #22563]
  2017-12-07 18:37 ` Florian Weimer
@ 2017-12-07 18:59   ` H.J. Lu
  2017-12-07 19:09     ` Florian Weimer
  0 siblings, 1 reply; 63+ messages in thread
From: H.J. Lu @ 2017-12-07 18:59 UTC (permalink / raw)
  To: Florian Weimer; +Cc: GNU C Library

On Thu, Dec 7, 2017 at 10:36 AM, Florian Weimer <fweimer@redhat.com> wrote:
> On 12/07/2017 06:40 PM, H.J. Lu wrote:
>>
>> On x86, padding in struct __jmp_buf_tag is used for shadow stack pointer
>> to support shadow stack in Intel Control-flow Enforcemen Technology.
>> Since the cancel_jmp_buf array is passed to setjmp and longjmp by
>> casting it to pointer to struct __jmp_buf_tag, it should be as large
>> as struct __jmp_buf_tag.  This patch adds pthread.h, pthreaddef.h and
>> pthreadP.h for Linux/x86 to define a new cancel_jmp_buf to match
>> struct __jmp_buf_tag.
>
>
> This seems the wrong thing to do.
>
> I don't think cancellation needs the shadow stack because none of the
> functions on the existing stack return during cancellation processing.
>
> Furthermore, SJLJ-style cancellation appears to defeat CET anyway, so I'm
> puzzled why aren't trying to get rid of this type of cancellation
> implementation instead because it looks like a fairly significant weakness
> (similar to SEH on Windows).
>
> If you want to preserve SJLJ-style cancellation as-is,
> __pthread_unwind_buf_t has sufficient padding, and you could simply use
> that.
>

No, shadow stack doesn't work that way.  Once it is turned on, it is on
until the process exits.   There is no such a thing of that cancellation
doesn't need shadow stack.


-- 
H.J.

^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: [PATCH 1/2] Linux/x86: Update cancel_jmp_buf to match __jmp_buf_tag [BZ #22563]
  2017-12-07 18:59   ` H.J. Lu
@ 2017-12-07 19:09     ` Florian Weimer
  2017-12-07 19:12       ` H.J. Lu
  0 siblings, 1 reply; 63+ messages in thread
From: Florian Weimer @ 2017-12-07 19:09 UTC (permalink / raw)
  To: H.J. Lu; +Cc: GNU C Library

On 12/07/2017 07:59 PM, H.J. Lu wrote:
> On Thu, Dec 7, 2017 at 10:36 AM, Florian Weimer <fweimer@redhat.com> wrote:
>> On 12/07/2017 06:40 PM, H.J. Lu wrote:
>>>
>>> On x86, padding in struct __jmp_buf_tag is used for shadow stack pointer
>>> to support shadow stack in Intel Control-flow Enforcemen Technology.
>>> Since the cancel_jmp_buf array is passed to setjmp and longjmp by
>>> casting it to pointer to struct __jmp_buf_tag, it should be as large
>>> as struct __jmp_buf_tag.  This patch adds pthread.h, pthreaddef.h and
>>> pthreadP.h for Linux/x86 to define a new cancel_jmp_buf to match
>>> struct __jmp_buf_tag.
>>
>>
>> This seems the wrong thing to do.
>>
>> I don't think cancellation needs the shadow stack because none of the
>> functions on the existing stack return during cancellation processing.
>>
>> Furthermore, SJLJ-style cancellation appears to defeat CET anyway, so I'm
>> puzzled why aren't trying to get rid of this type of cancellation
>> implementation instead because it looks like a fairly significant weakness
>> (similar to SEH on Windows).
>>
>> If you want to preserve SJLJ-style cancellation as-is,
>> __pthread_unwind_buf_t has sufficient padding, and you could simply use
>> that.
>>
> 
> No, shadow stack doesn't work that way.  Once it is turned on, it is on
> until the process exits.   There is no such a thing of that cancellation
> doesn't need shadow stack.

Sorry, what exactly is stored on the shadow stack?  I assumed it was for 
verification of the targets of ret instructions.

In this case, don't need to unwind the shadow stack (or preserve its 
contents) because there are no returns from existing stack frames once 
cancellation has started.

Florian

^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: [PATCH 1/2] Linux/x86: Update cancel_jmp_buf to match __jmp_buf_tag [BZ #22563]
  2017-12-07 19:09     ` Florian Weimer
@ 2017-12-07 19:12       ` H.J. Lu
  2017-12-07 19:14         ` Florian Weimer
  0 siblings, 1 reply; 63+ messages in thread
From: H.J. Lu @ 2017-12-07 19:12 UTC (permalink / raw)
  To: Florian Weimer; +Cc: GNU C Library

On Thu, Dec 7, 2017 at 11:09 AM, Florian Weimer <fweimer@redhat.com> wrote:
> On 12/07/2017 07:59 PM, H.J. Lu wrote:
>>
>> On Thu, Dec 7, 2017 at 10:36 AM, Florian Weimer <fweimer@redhat.com>
>> wrote:
>>>
>>> On 12/07/2017 06:40 PM, H.J. Lu wrote:
>>>>
>>>>
>>>> On x86, padding in struct __jmp_buf_tag is used for shadow stack pointer
>>>> to support shadow stack in Intel Control-flow Enforcemen Technology.
>>>> Since the cancel_jmp_buf array is passed to setjmp and longjmp by
>>>> casting it to pointer to struct __jmp_buf_tag, it should be as large
>>>> as struct __jmp_buf_tag.  This patch adds pthread.h, pthreaddef.h and
>>>> pthreadP.h for Linux/x86 to define a new cancel_jmp_buf to match
>>>> struct __jmp_buf_tag.
>>>
>>>
>>>
>>> This seems the wrong thing to do.
>>>
>>> I don't think cancellation needs the shadow stack because none of the
>>> functions on the existing stack return during cancellation processing.
>>>
>>> Furthermore, SJLJ-style cancellation appears to defeat CET anyway, so I'm
>>> puzzled why aren't trying to get rid of this type of cancellation
>>> implementation instead because it looks like a fairly significant
>>> weakness
>>> (similar to SEH on Windows).
>>>
>>> If you want to preserve SJLJ-style cancellation as-is,
>>> __pthread_unwind_buf_t has sufficient padding, and you could simply use
>>> that.
>>>
>>
>> No, shadow stack doesn't work that way.  Once it is turned on, it is on
>> until the process exits.   There is no such a thing of that cancellation
>> doesn't need shadow stack.
>
>
> Sorry, what exactly is stored on the shadow stack?  I assumed it was for
> verification of the targets of ret instructions.
>
> In this case, don't need to unwind the shadow stack (or preserve its
> contents) because there are no returns from existing stack frames once
> cancellation has started.
>

Shadow stack is the similar to normal call stack without local variables.
SHSTK checks  the return address of EACH  "RET"  instruction against
shadow stack.


-- 
H.J.

^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: [PATCH 1/2] Linux/x86: Update cancel_jmp_buf to match __jmp_buf_tag [BZ #22563]
  2017-12-07 19:12       ` H.J. Lu
@ 2017-12-07 19:14         ` Florian Weimer
  2017-12-07 19:19           ` H.J. Lu
  0 siblings, 1 reply; 63+ messages in thread
From: Florian Weimer @ 2017-12-07 19:14 UTC (permalink / raw)
  To: H.J. Lu; +Cc: GNU C Library

On 12/07/2017 08:12 PM, H.J. Lu wrote:
>> Sorry, what exactly is stored on the shadow stack?  I assumed it was for
>> verification of the targets of ret instructions.
>>
>> In this case, don't need to unwind the shadow stack (or preserve its
>> contents) because there are no returns from existing stack frames once
>> cancellation has started.
>>
> Shadow stack is the similar to normal call stack without local variables.
> SHSTK checks  the return address of EACH  "RET"  instruction against
> shadow stack.

Then the shadow stack contents at the time of cancellation does not 
matter because all future RET instructions on this thread will match 
CALLs which happened *after* cancellation.  (In other words, I still 
think I'm right about this.)

Thanks,
Florian

^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: [PATCH 1/2] Linux/x86: Update cancel_jmp_buf to match __jmp_buf_tag [BZ #22563]
  2017-12-07 19:14         ` Florian Weimer
@ 2017-12-07 19:19           ` H.J. Lu
  2017-12-07 19:25             ` Florian Weimer
  0 siblings, 1 reply; 63+ messages in thread
From: H.J. Lu @ 2017-12-07 19:19 UTC (permalink / raw)
  To: Florian Weimer; +Cc: GNU C Library

On Thu, Dec 7, 2017 at 11:14 AM, Florian Weimer <fweimer@redhat.com> wrote:
> On 12/07/2017 08:12 PM, H.J. Lu wrote:
>>>
>>> Sorry, what exactly is stored on the shadow stack?  I assumed it was for
>>> verification of the targets of ret instructions.
>>>
>>> In this case, don't need to unwind the shadow stack (or preserve its
>>> contents) because there are no returns from existing stack frames once
>>> cancellation has started.
>>>
>> Shadow stack is the similar to normal call stack without local variables.
>> SHSTK checks  the return address of EACH  "RET"  instruction against
>> shadow stack.
>
>
> Then the shadow stack contents at the time of cancellation does not matter
> because all future RET instructions on this thread will match CALLs which
> happened *after* cancellation.  (In other words, I still think I'm right
> about this.)
>

We are updating setjmp/lonjmp to save and restore shadow stack pointer:

https://sourceware.org/git/?p=glibc.git;a=commit;h=ac195a2d554e3fb577e44474faf3ed7f4521de9f



-- 
H.J.

^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: [PATCH 1/2] Linux/x86: Update cancel_jmp_buf to match __jmp_buf_tag [BZ #22563]
  2017-12-07 19:19           ` H.J. Lu
@ 2017-12-07 19:25             ` Florian Weimer
  2017-12-07 19:35               ` H.J. Lu
  0 siblings, 1 reply; 63+ messages in thread
From: Florian Weimer @ 2017-12-07 19:25 UTC (permalink / raw)
  To: H.J. Lu; +Cc: GNU C Library

On 12/07/2017 08:19 PM, H.J. Lu wrote:
> On Thu, Dec 7, 2017 at 11:14 AM, Florian Weimer <fweimer@redhat.com> wrote:
>> On 12/07/2017 08:12 PM, H.J. Lu wrote:
>>>>
>>>> Sorry, what exactly is stored on the shadow stack?  I assumed it was for
>>>> verification of the targets of ret instructions.
>>>>
>>>> In this case, don't need to unwind the shadow stack (or preserve its
>>>> contents) because there are no returns from existing stack frames once
>>>> cancellation has started.
>>>>
>>> Shadow stack is the similar to normal call stack without local variables.
>>> SHSTK checks  the return address of EACH  "RET"  instruction against
>>> shadow stack.
>>
>>
>> Then the shadow stack contents at the time of cancellation does not matter
>> because all future RET instructions on this thread will match CALLs which
>> happened *after* cancellation.  (In other words, I still think I'm right
>> about this.)
>>
> 
> We are updating setjmp/lonjmp to save and restore shadow stack pointer:
> 
> https://sourceware.org/git/?p=glibc.git;a=commit;h=ac195a2d554e3fb577e44474faf3ed7f4521de9f

Please try to understand what I wrote.  You don't need the restore 
during cancellation handling:

     if (__glibc_unlikely (__not_first_call))	      \
       {						      \
	__cancel_routine (__cancel_arg);	      \
	__pthread_unwind_next (&__cancel_buf);	      \
	/* NOTREACHED */			      \
       }						      \

Florian

^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: [PATCH 1/2] Linux/x86: Update cancel_jmp_buf to match __jmp_buf_tag [BZ #22563]
  2017-12-07 19:25             ` Florian Weimer
@ 2017-12-07 19:35               ` H.J. Lu
  2017-12-08  2:25                 ` H.J. Lu
  0 siblings, 1 reply; 63+ messages in thread
From: H.J. Lu @ 2017-12-07 19:35 UTC (permalink / raw)
  To: Florian Weimer; +Cc: GNU C Library

On Thu, Dec 7, 2017 at 11:25 AM, Florian Weimer <fweimer@redhat.com> wrote:
> On 12/07/2017 08:19 PM, H.J. Lu wrote:
>>
>> On Thu, Dec 7, 2017 at 11:14 AM, Florian Weimer <fweimer@redhat.com>
>> wrote:
>>>
>>> On 12/07/2017 08:12 PM, H.J. Lu wrote:
>>>>>
>>>>>
>>>>> Sorry, what exactly is stored on the shadow stack?  I assumed it was
>>>>> for
>>>>> verification of the targets of ret instructions.
>>>>>
>>>>> In this case, don't need to unwind the shadow stack (or preserve its
>>>>> contents) because there are no returns from existing stack frames once
>>>>> cancellation has started.
>>>>>
>>>> Shadow stack is the similar to normal call stack without local
>>>> variables.
>>>> SHSTK checks  the return address of EACH  "RET"  instruction against
>>>> shadow stack.
>>>
>>>
>>>
>>> Then the shadow stack contents at the time of cancellation does not
>>> matter
>>> because all future RET instructions on this thread will match CALLs which
>>> happened *after* cancellation.  (In other words, I still think I'm right
>>> about this.)
>>>
>>
>> We are updating setjmp/lonjmp to save and restore shadow stack pointer:
>>
>>
>> https://sourceware.org/git/?p=glibc.git;a=commit;h=ac195a2d554e3fb577e44474faf3ed7f4521de9f
>
>
> Please try to understand what I wrote.  You don't need the restore during
> cancellation handling:
>
>     if (__glibc_unlikely (__not_first_call))          \
>       {                                               \
>         __cancel_routine (__cancel_arg);              \
>         __pthread_unwind_next (&__cancel_buf);        \
>         /* NOTREACHED */                              \
>       }                                               \
>

Who will sync shadow stack with call stack?


-- 
H.J.

^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: [PATCH 1/2] Linux/x86: Update cancel_jmp_buf to match __jmp_buf_tag [BZ #22563]
  2017-12-07 19:35               ` H.J. Lu
@ 2017-12-08  2:25                 ` H.J. Lu
  2017-12-14 13:06                   ` H.J. Lu
  2017-12-18 10:25                   ` Florian Weimer
  0 siblings, 2 replies; 63+ messages in thread
From: H.J. Lu @ 2017-12-08  2:25 UTC (permalink / raw)
  To: Florian Weimer; +Cc: GNU C Library

[-- Attachment #1: Type: text/plain, Size: 5217 bytes --]

On Thu, Dec 7, 2017 at 11:35 AM, H.J. Lu <hjl.tools@gmail.com> wrote:
> On Thu, Dec 7, 2017 at 11:25 AM, Florian Weimer <fweimer@redhat.com> wrote:
>> On 12/07/2017 08:19 PM, H.J. Lu wrote:
>>>
>>> On Thu, Dec 7, 2017 at 11:14 AM, Florian Weimer <fweimer@redhat.com>
>>> wrote:
>>>>
>>>> On 12/07/2017 08:12 PM, H.J. Lu wrote:
>>>>>>
>>>>>>
>>>>>> Sorry, what exactly is stored on the shadow stack?  I assumed it was
>>>>>> for
>>>>>> verification of the targets of ret instructions.
>>>>>>
>>>>>> In this case, don't need to unwind the shadow stack (or preserve its
>>>>>> contents) because there are no returns from existing stack frames once
>>>>>> cancellation has started.
>>>>>>
>>>>> Shadow stack is the similar to normal call stack without local
>>>>> variables.
>>>>> SHSTK checks  the return address of EACH  "RET"  instruction against
>>>>> shadow stack.
>>>>
>>>>
>>>>
>>>> Then the shadow stack contents at the time of cancellation does not
>>>> matter
>>>> because all future RET instructions on this thread will match CALLs which
>>>> happened *after* cancellation.  (In other words, I still think I'm right
>>>> about this.)
>>>>
>>>
>>> We are updating setjmp/lonjmp to save and restore shadow stack pointer:
>>>
>>>
>>> https://sourceware.org/git/?p=glibc.git;a=commit;h=ac195a2d554e3fb577e44474faf3ed7f4521de9f
>>
>>
>> Please try to understand what I wrote.  You don't need the restore during
>> cancellation handling:
>>
>>     if (__glibc_unlikely (__not_first_call))          \
>>       {                                               \
>>         __cancel_routine (__cancel_arg);              \
>>         __pthread_unwind_next (&__cancel_buf);        \
>>         /* NOTREACHED */                              \
>>       }                                               \
>>
>
> Who will sync shadow stack with call stack?
>

Here is call stack during stack unwind:

(gdb) bt
#0  __longjmp () at ../sysdeps/unix/sysv/linux/x86_64/__longjmp.S:30
#1  0x00007ffff7837f5f in __libc_siglongjmp (env=env@entry=0x7ffff7800da0,
    val=val@entry=1) at longjmp.c:39
#2  0x00007ffff7bc899d in unwind_stop (version=<optimized out>,
    actions=<optimized out>, exc_class=<optimized out>,
    exc_obj=<optimized out>, context=<optimized out>,
    stop_parameter=0x7ffff7800da0) at unwind.c:94
#3  0x00007ffff6df9b6e in _Unwind_ForcedUnwind_Phase2 (
    exc=exc@entry=0x7ffff7801d70, context=context@entry=0x7ffff78005d0,
    frames_p=frames_p@entry=0x7ffff78004d8)
    at /export/gnu/import/git/sources/gcc/libgcc/unwind.inc:170
#4  0x00007ffff6dfa1c0 in _Unwind_ForcedUnwind (exc=0x7ffff7801d70,
    stop=stop@entry=0x7ffff7bc88e0 <unwind_stop>,
    stop_argument=<optimized out>)
    at /export/gnu/import/git/sources/gcc/libgcc/unwind.inc:217
#5  0x00007ffff7bc8a84 in __GI___pthread_unwind (buf=<optimized out>)
    at unwind.c:121
#6  0x00007ffff7bbe46a in __do_cancel () at ./pthreadP.h:297
#7  sigcancel_handler (sig=<optimized out>, si=0x7ffff7800870,
    ctx=<optimized out>) at nptl-init.c:216
#8  <signal handler called>
#9  0x00007ffff7bc8f04 in __libc_read (fd=fd@entry=3,
    buf=buf@entry=0x7ffff7800d30, nbytes=nbytes@entry=100)
---Type <return> to continue, or q <return> to quit---
   sv/linux/read.c:27
#10 0x00000000004064a0 in tf_read (arg=<optimized out>) at tst-cancel4.c:102
#11 0x00007ffff7bbfcde in start_thread (arg=<optimized out>)
    at pthread_create.c:463
#12 0x00007ffff78f5f73 in clone ()
    at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
(gdb) f 10
#10 0x00000000004064a0 in tf_read (arg=<optimized out>) at tst-cancel4.c:102
102   s = read (fd, buf, sizeof (buf));
(gdb) list
97
98   ssize_t s;
99   pthread_cleanup_push (cl, NULL);
100
101   char buf[100];
102   s = read (fd, buf, sizeof (buf));
103
104   pthread_cleanup_pop (0);
105
106   FAIL_EXIT1 ("read returns with %zd", s);
(gdb)

# define pthread_cleanup_push(routine, arg) \
  do {                                                                        \
    __pthread_unwind_buf_t __cancel_buf;                                      \
    void (*__cancel_routine) (void *) = (routine);                            \
    void *__cancel_arg = (arg);                                               \
    int __not_first_call = __sigsetjmp ((struct __jmp_buf_tag *) (void *)     \
                                        __cancel_buf.__cancel_jmp_buf, 0);    \
    if (__glibc_unlikely (__not_first_call))                                  \
      {                                                                       \
        __cancel_routine (__cancel_arg);                                      \
        __pthread_unwind_next (&__cancel_buf);                                \
        /* NOTREACHED */                                                      \
      }

To unwind shadow stack, we need to save shadow stack pointer in
__cancel_buf.   This updated patch adds bits/types/__cancel_jmp_buf_tag.h
to define struct __cancel_jmp_buf_tag so that Linux/x86 can add saved_mask
to __cancel_jmp_buf.   We will check if shadow stack is enabled before saving
and restoring shadow stack pointer so that it works with the old smaller
cancel_jmp_buf which doesn't have space for shadow stack pointer.


-- 
H.J.

[-- Attachment #2: 0001-Linux-x86-Update-cancel_jmp_buf-to-match-__jmp_buf_t.patch --]
[-- Type: text/x-patch, Size: 8912 bytes --]

From b6aad5a9958354e236f42877575e9f76f90348d1 Mon Sep 17 00:00:00 2001
From: "H.J. Lu" <hjl.tools@gmail.com>
Date: Wed, 6 Dec 2017 15:00:46 -0800
Subject: [PATCH] Linux/x86: Update cancel_jmp_buf to match __jmp_buf_tag [BZ
 #22563]

On x86, padding in struct __jmp_buf_tag is used for shadow stack pointer
to support shadow stack in Intel Control-flow Enforcemen Technology.
Since the cancel_jmp_buf array is passed to setjmp and longjmp by
casting it to pointer to struct __jmp_buf_tag, it should be as large
as struct __jmp_buf_tag.

This patch adds bits/types/__cancel_jmp_buf_tag.h to define struct
__cancel_jmp_buf_tag so that Linux/x86 can add saved_mask to
cancel_jmp_buf.

Tested by build-many-glibcs.py.

	[BZ #22563]
	* bits/types/__cancel_jmp_buf_tag.h: New file.
	* sysdeps/unix/sysv/linux/x86/bits/types/__cancel_jmp_buf_tag.h
	* sysdeps/unix/sysv/linux/x86/pthreaddef.h: Likewise.
	* sysdeps/unix/sysv/linux/x86/nptl/pthreadP.h: Likewise.
	* nptl/Makefile (headers): Add
	bits/types/__cancel_jmp_buf_tag.h.
	* nptl/descr.h [NEED_SAVED_MASK_IN_CANCEL_JMP_BUF]
	(pthread_unwind_buf): Add saved_mask to cancel_jmp_buf.
	* sysdeps/nptl/pthread.h: Include
	<bits/types/__cancel_jmp_buf_tag.h>.
	(__pthread_unwind_buf_t): Use struct __cancel_jmp_buf_tag with
	__cancel_jmp_buf.
---
 bits/types/__cancel_jmp_buf_tag.h                  | 28 +++++++++++++++++
 nptl/Makefile                                      |  3 +-
 nptl/descr.h                                       |  3 ++
 sysdeps/nptl/pthread.h                             |  7 ++---
 .../linux/x86/bits/types/__cancel_jmp_buf_tag.h    | 31 +++++++++++++++++++
 sysdeps/unix/sysv/linux/x86/nptl/pthreadP.h        | 36 ++++++++++++++++++++++
 sysdeps/unix/sysv/linux/x86/pthreaddef.h           | 22 +++++++++++++
 7 files changed, 124 insertions(+), 6 deletions(-)
 create mode 100644 bits/types/__cancel_jmp_buf_tag.h
 create mode 100644 sysdeps/unix/sysv/linux/x86/bits/types/__cancel_jmp_buf_tag.h
 create mode 100644 sysdeps/unix/sysv/linux/x86/nptl/pthreadP.h
 create mode 100644 sysdeps/unix/sysv/linux/x86/pthreaddef.h

diff --git a/bits/types/__cancel_jmp_buf_tag.h b/bits/types/__cancel_jmp_buf_tag.h
new file mode 100644
index 0000000000..c843f44239
--- /dev/null
+++ b/bits/types/__cancel_jmp_buf_tag.h
@@ -0,0 +1,28 @@
+/* Define struct __cancel_jmp_buf_tag.
+   Copyright (C) 2017 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/>.  */
+
+#ifndef ____cancel_jmp_buf_tag_defined
+#define ____cancel_jmp_buf_tag_defined 1
+
+struct __cancel_jmp_buf_tag
+  {
+    __jmp_buf __cancel_jmp_buf;
+    int __mask_was_saved;
+  };
+
+#endif
diff --git a/nptl/Makefile b/nptl/Makefile
index 11e6ecd88b..46e110773c 100644
--- a/nptl/Makefile
+++ b/nptl/Makefile
@@ -22,7 +22,8 @@ subdir	:= nptl
 
 include ../Makeconfig
 
-headers := pthread.h semaphore.h bits/semaphore.h
+headers := pthread.h semaphore.h bits/semaphore.h \
+	   bits/types/__cancel_jmp_buf_tag.h
 
 extra-libs := libpthread
 extra-libs-others := $(extra-libs)
diff --git a/nptl/descr.h b/nptl/descr.h
index c83b17b674..fdeb397eab 100644
--- a/nptl/descr.h
+++ b/nptl/descr.h
@@ -65,6 +65,9 @@ struct pthread_unwind_buf
   {
     __jmp_buf jmp_buf;
     int mask_was_saved;
+#ifdef NEED_SAVED_MASK_IN_CANCEL_JMP_BUF
+    __sigset_t saved_mask;
+#endif
   } cancel_jmp_buf[1];
 
   union
diff --git a/sysdeps/nptl/pthread.h b/sysdeps/nptl/pthread.h
index 2b2b386ab3..787ac6e4cd 100644
--- a/sysdeps/nptl/pthread.h
+++ b/sysdeps/nptl/pthread.h
@@ -27,6 +27,7 @@
 #include <bits/setjmp.h>
 #include <bits/wordsize.h>
 #include <bits/types/struct_timespec.h>
+#include <bits/types/__cancel_jmp_buf_tag.h>
 
 
 /* Detach state.  */
@@ -523,11 +524,7 @@ extern void pthread_testcancel (void);
 
 typedef struct
 {
-  struct
-  {
-    __jmp_buf __cancel_jmp_buf;
-    int __mask_was_saved;
-  } __cancel_jmp_buf[1];
+  struct __cancel_jmp_buf_tag __cancel_jmp_buf[1];
   void *__pad[4];
 } __pthread_unwind_buf_t __attribute__ ((__aligned__));
 
diff --git a/sysdeps/unix/sysv/linux/x86/bits/types/__cancel_jmp_buf_tag.h b/sysdeps/unix/sysv/linux/x86/bits/types/__cancel_jmp_buf_tag.h
new file mode 100644
index 0000000000..830a6ec90c
--- /dev/null
+++ b/sysdeps/unix/sysv/linux/x86/bits/types/__cancel_jmp_buf_tag.h
@@ -0,0 +1,31 @@
+/* Define struct __cancel_jmp_buf_tag.
+   Copyright (C) 2017 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/>.  */
+
+#ifndef ____cancel_jmp_buf_tag_defined
+#define ____cancel_jmp_buf_tag_defined 1
+
+#include <bits/types/__sigset_t.h>
+
+struct __cancel_jmp_buf_tag
+  {
+    __jmp_buf __cancel_jmp_buf;
+    int __mask_was_saved;
+    __sigset_t __saved_mask;
+  };
+
+#endif
diff --git a/sysdeps/unix/sysv/linux/x86/nptl/pthreadP.h b/sysdeps/unix/sysv/linux/x86/nptl/pthreadP.h
new file mode 100644
index 0000000000..8c36ba3a5d
--- /dev/null
+++ b/sysdeps/unix/sysv/linux/x86/nptl/pthreadP.h
@@ -0,0 +1,36 @@
+/* Internal pthread header.  Linux/x86 version.
+   Copyright (C) 2017 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/>.  */
+
+#include_next <nptl/pthreadP.h>
+
+#ifndef _PTHREADP_H_X86
+#define _PTHREADP_H_X86 1
+
+extern struct pthread_unwind_buf ____pthread_unwind_buf_private;
+
+_Static_assert (sizeof (____pthread_unwind_buf_private.cancel_jmp_buf)
+		>= sizeof (struct __jmp_buf_tag),
+		"size of cancel_jmp_buf < sizeof __jmp_buf_tag");
+
+extern __pthread_unwind_buf_t ____pthread_unwind_buf;
+
+_Static_assert (sizeof (____pthread_unwind_buf.__cancel_jmp_buf)
+		>= sizeof (struct __jmp_buf_tag),
+		"size of __cancel_jmp_buf < sizeof __jmp_buf_tag");
+
+#endif
diff --git a/sysdeps/unix/sysv/linux/x86/pthreaddef.h b/sysdeps/unix/sysv/linux/x86/pthreaddef.h
new file mode 100644
index 0000000000..89d19d60a1
--- /dev/null
+++ b/sysdeps/unix/sysv/linux/x86/pthreaddef.h
@@ -0,0 +1,22 @@
+/* Pthread macros.  Linux/x86 version.
+   Copyright (C) 2017 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/>.  */
+
+#include_next <pthreaddef.h>
+
+/* Need saved_mask in cancel_jmp_buf.  */
+#define NEED_SAVED_MASK_IN_CANCEL_JMP_BUF 1
-- 
2.14.3


^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: [PATCH 1/2] Linux/x86: Update cancel_jmp_buf to match __jmp_buf_tag [BZ #22563]
  2017-12-08  2:25                 ` H.J. Lu
@ 2017-12-14 13:06                   ` H.J. Lu
  2017-12-15 17:43                     ` H.J. Lu
  2017-12-18 10:25                   ` Florian Weimer
  1 sibling, 1 reply; 63+ messages in thread
From: H.J. Lu @ 2017-12-14 13:06 UTC (permalink / raw)
  To: Florian Weimer; +Cc: GNU C Library

On Thu, Dec 7, 2017 at 6:25 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
> On Thu, Dec 7, 2017 at 11:35 AM, H.J. Lu <hjl.tools@gmail.com> wrote:
>> On Thu, Dec 7, 2017 at 11:25 AM, Florian Weimer <fweimer@redhat.com> wrote:
>>> On 12/07/2017 08:19 PM, H.J. Lu wrote:
>>>>
>>>> On Thu, Dec 7, 2017 at 11:14 AM, Florian Weimer <fweimer@redhat.com>
>>>> wrote:
>>>>>
>>>>> On 12/07/2017 08:12 PM, H.J. Lu wrote:
>>>>>>>
>>>>>>>
>>>>>>> Sorry, what exactly is stored on the shadow stack?  I assumed it was
>>>>>>> for
>>>>>>> verification of the targets of ret instructions.
>>>>>>>
>>>>>>> In this case, don't need to unwind the shadow stack (or preserve its
>>>>>>> contents) because there are no returns from existing stack frames once
>>>>>>> cancellation has started.
>>>>>>>
>>>>>> Shadow stack is the similar to normal call stack without local
>>>>>> variables.
>>>>>> SHSTK checks  the return address of EACH  "RET"  instruction against
>>>>>> shadow stack.
>>>>>
>>>>>
>>>>>
>>>>> Then the shadow stack contents at the time of cancellation does not
>>>>> matter
>>>>> because all future RET instructions on this thread will match CALLs which
>>>>> happened *after* cancellation.  (In other words, I still think I'm right
>>>>> about this.)
>>>>>
>>>>
>>>> We are updating setjmp/lonjmp to save and restore shadow stack pointer:
>>>>
>>>>
>>>> https://sourceware.org/git/?p=glibc.git;a=commit;h=ac195a2d554e3fb577e44474faf3ed7f4521de9f
>>>
>>>
>>> Please try to understand what I wrote.  You don't need the restore during
>>> cancellation handling:
>>>
>>>     if (__glibc_unlikely (__not_first_call))          \
>>>       {                                               \
>>>         __cancel_routine (__cancel_arg);              \
>>>         __pthread_unwind_next (&__cancel_buf);        \
>>>         /* NOTREACHED */                              \
>>>       }                                               \
>>>
>>
>> Who will sync shadow stack with call stack?
>>
>
> Here is call stack during stack unwind:
>
> (gdb) bt
> #0  __longjmp () at ../sysdeps/unix/sysv/linux/x86_64/__longjmp.S:30
> #1  0x00007ffff7837f5f in __libc_siglongjmp (env=env@entry=0x7ffff7800da0,
>     val=val@entry=1) at longjmp.c:39
> #2  0x00007ffff7bc899d in unwind_stop (version=<optimized out>,
>     actions=<optimized out>, exc_class=<optimized out>,
>     exc_obj=<optimized out>, context=<optimized out>,
>     stop_parameter=0x7ffff7800da0) at unwind.c:94
> #3  0x00007ffff6df9b6e in _Unwind_ForcedUnwind_Phase2 (
>     exc=exc@entry=0x7ffff7801d70, context=context@entry=0x7ffff78005d0,
>     frames_p=frames_p@entry=0x7ffff78004d8)
>     at /export/gnu/import/git/sources/gcc/libgcc/unwind.inc:170
> #4  0x00007ffff6dfa1c0 in _Unwind_ForcedUnwind (exc=0x7ffff7801d70,
>     stop=stop@entry=0x7ffff7bc88e0 <unwind_stop>,
>     stop_argument=<optimized out>)
>     at /export/gnu/import/git/sources/gcc/libgcc/unwind.inc:217
> #5  0x00007ffff7bc8a84 in __GI___pthread_unwind (buf=<optimized out>)
>     at unwind.c:121
> #6  0x00007ffff7bbe46a in __do_cancel () at ./pthreadP.h:297
> #7  sigcancel_handler (sig=<optimized out>, si=0x7ffff7800870,
>     ctx=<optimized out>) at nptl-init.c:216
> #8  <signal handler called>
> #9  0x00007ffff7bc8f04 in __libc_read (fd=fd@entry=3,
>     buf=buf@entry=0x7ffff7800d30, nbytes=nbytes@entry=100)
> ---Type <return> to continue, or q <return> to quit---
>    sv/linux/read.c:27
> #10 0x00000000004064a0 in tf_read (arg=<optimized out>) at tst-cancel4.c:102
> #11 0x00007ffff7bbfcde in start_thread (arg=<optimized out>)
>     at pthread_create.c:463
> #12 0x00007ffff78f5f73 in clone ()
>     at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
> (gdb) f 10
> #10 0x00000000004064a0 in tf_read (arg=<optimized out>) at tst-cancel4.c:102
> 102   s = read (fd, buf, sizeof (buf));
> (gdb) list
> 97
> 98   ssize_t s;
> 99   pthread_cleanup_push (cl, NULL);
> 100
> 101   char buf[100];
> 102   s = read (fd, buf, sizeof (buf));
> 103
> 104   pthread_cleanup_pop (0);
> 105
> 106   FAIL_EXIT1 ("read returns with %zd", s);
> (gdb)
>
> # define pthread_cleanup_push(routine, arg) \
>   do {                                                                        \
>     __pthread_unwind_buf_t __cancel_buf;                                      \
>     void (*__cancel_routine) (void *) = (routine);                            \
>     void *__cancel_arg = (arg);                                               \
>     int __not_first_call = __sigsetjmp ((struct __jmp_buf_tag *) (void *)     \
>                                         __cancel_buf.__cancel_jmp_buf, 0);    \
>     if (__glibc_unlikely (__not_first_call))                                  \
>       {                                                                       \
>         __cancel_routine (__cancel_arg);                                      \
>         __pthread_unwind_next (&__cancel_buf);                                \
>         /* NOTREACHED */                                                      \
>       }
>
> To unwind shadow stack, we need to save shadow stack pointer in
> __cancel_buf.   This updated patch adds bits/types/__cancel_jmp_buf_tag.h
> to define struct __cancel_jmp_buf_tag so that Linux/x86 can add saved_mask
> to __cancel_jmp_buf.   We will check if shadow stack is enabled before saving
> and restoring shadow stack pointer so that it works with the old smaller
> cancel_jmp_buf which doesn't have space for shadow stack pointer.
>

Any comments?

-- 
H.J.

^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: [PATCH 1/2] Linux/x86: Update cancel_jmp_buf to match __jmp_buf_tag [BZ #22563]
  2017-12-14 13:06                   ` H.J. Lu
@ 2017-12-15 17:43                     ` H.J. Lu
  0 siblings, 0 replies; 63+ messages in thread
From: H.J. Lu @ 2017-12-15 17:43 UTC (permalink / raw)
  To: Florian Weimer; +Cc: GNU C Library

On Thu, Dec 14, 2017 at 5:06 AM, H.J. Lu <hjl.tools@gmail.com> wrote:
> On Thu, Dec 7, 2017 at 6:25 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
>> On Thu, Dec 7, 2017 at 11:35 AM, H.J. Lu <hjl.tools@gmail.com> wrote:
>>> On Thu, Dec 7, 2017 at 11:25 AM, Florian Weimer <fweimer@redhat.com> wrote:
>>>> On 12/07/2017 08:19 PM, H.J. Lu wrote:
>>>>>
>>>>> On Thu, Dec 7, 2017 at 11:14 AM, Florian Weimer <fweimer@redhat.com>
>>>>> wrote:
>>>>>>
>>>>>> On 12/07/2017 08:12 PM, H.J. Lu wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> Sorry, what exactly is stored on the shadow stack?  I assumed it was
>>>>>>>> for
>>>>>>>> verification of the targets of ret instructions.
>>>>>>>>
>>>>>>>> In this case, don't need to unwind the shadow stack (or preserve its
>>>>>>>> contents) because there are no returns from existing stack frames once
>>>>>>>> cancellation has started.
>>>>>>>>
>>>>>>> Shadow stack is the similar to normal call stack without local
>>>>>>> variables.
>>>>>>> SHSTK checks  the return address of EACH  "RET"  instruction against
>>>>>>> shadow stack.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Then the shadow stack contents at the time of cancellation does not
>>>>>> matter
>>>>>> because all future RET instructions on this thread will match CALLs which
>>>>>> happened *after* cancellation.  (In other words, I still think I'm right
>>>>>> about this.)
>>>>>>
>>>>>
>>>>> We are updating setjmp/lonjmp to save and restore shadow stack pointer:
>>>>>
>>>>>
>>>>> https://sourceware.org/git/?p=glibc.git;a=commit;h=ac195a2d554e3fb577e44474faf3ed7f4521de9f
>>>>
>>>>
>>>> Please try to understand what I wrote.  You don't need the restore during
>>>> cancellation handling:
>>>>
>>>>     if (__glibc_unlikely (__not_first_call))          \
>>>>       {                                               \
>>>>         __cancel_routine (__cancel_arg);              \
>>>>         __pthread_unwind_next (&__cancel_buf);        \
>>>>         /* NOTREACHED */                              \
>>>>       }                                               \
>>>>
>>>
>>> Who will sync shadow stack with call stack?
>>>
>>
>> Here is call stack during stack unwind:
>>
>> (gdb) bt
>> #0  __longjmp () at ../sysdeps/unix/sysv/linux/x86_64/__longjmp.S:30
>> #1  0x00007ffff7837f5f in __libc_siglongjmp (env=env@entry=0x7ffff7800da0,
>>     val=val@entry=1) at longjmp.c:39
>> #2  0x00007ffff7bc899d in unwind_stop (version=<optimized out>,
>>     actions=<optimized out>, exc_class=<optimized out>,
>>     exc_obj=<optimized out>, context=<optimized out>,
>>     stop_parameter=0x7ffff7800da0) at unwind.c:94
>> #3  0x00007ffff6df9b6e in _Unwind_ForcedUnwind_Phase2 (
>>     exc=exc@entry=0x7ffff7801d70, context=context@entry=0x7ffff78005d0,
>>     frames_p=frames_p@entry=0x7ffff78004d8)
>>     at /export/gnu/import/git/sources/gcc/libgcc/unwind.inc:170
>> #4  0x00007ffff6dfa1c0 in _Unwind_ForcedUnwind (exc=0x7ffff7801d70,
>>     stop=stop@entry=0x7ffff7bc88e0 <unwind_stop>,
>>     stop_argument=<optimized out>)
>>     at /export/gnu/import/git/sources/gcc/libgcc/unwind.inc:217
>> #5  0x00007ffff7bc8a84 in __GI___pthread_unwind (buf=<optimized out>)
>>     at unwind.c:121
>> #6  0x00007ffff7bbe46a in __do_cancel () at ./pthreadP.h:297
>> #7  sigcancel_handler (sig=<optimized out>, si=0x7ffff7800870,
>>     ctx=<optimized out>) at nptl-init.c:216
>> #8  <signal handler called>
>> #9  0x00007ffff7bc8f04 in __libc_read (fd=fd@entry=3,
>>     buf=buf@entry=0x7ffff7800d30, nbytes=nbytes@entry=100)
>> ---Type <return> to continue, or q <return> to quit---
>>    sv/linux/read.c:27
>> #10 0x00000000004064a0 in tf_read (arg=<optimized out>) at tst-cancel4.c:102
>> #11 0x00007ffff7bbfcde in start_thread (arg=<optimized out>)
>>     at pthread_create.c:463
>> #12 0x00007ffff78f5f73 in clone ()
>>     at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
>> (gdb) f 10
>> #10 0x00000000004064a0 in tf_read (arg=<optimized out>) at tst-cancel4.c:102
>> 102   s = read (fd, buf, sizeof (buf));
>> (gdb) list
>> 97
>> 98   ssize_t s;
>> 99   pthread_cleanup_push (cl, NULL);
>> 100
>> 101   char buf[100];
>> 102   s = read (fd, buf, sizeof (buf));
>> 103
>> 104   pthread_cleanup_pop (0);
>> 105
>> 106   FAIL_EXIT1 ("read returns with %zd", s);
>> (gdb)
>>
>> # define pthread_cleanup_push(routine, arg) \
>>   do {                                                                        \
>>     __pthread_unwind_buf_t __cancel_buf;                                      \
>>     void (*__cancel_routine) (void *) = (routine);                            \
>>     void *__cancel_arg = (arg);                                               \
>>     int __not_first_call = __sigsetjmp ((struct __jmp_buf_tag *) (void *)     \
>>                                         __cancel_buf.__cancel_jmp_buf, 0);    \
>>     if (__glibc_unlikely (__not_first_call))                                  \
>>       {                                                                       \
>>         __cancel_routine (__cancel_arg);                                      \
>>         __pthread_unwind_next (&__cancel_buf);                                \
>>         /* NOTREACHED */                                                      \
>>       }
>>
>> To unwind shadow stack, we need to save shadow stack pointer in
>> __cancel_buf.   This updated patch adds bits/types/__cancel_jmp_buf_tag.h
>> to define struct __cancel_jmp_buf_tag so that Linux/x86 can add saved_mask
>> to __cancel_jmp_buf.   We will check if shadow stack is enabled before saving
>> and restoring shadow stack pointer so that it works with the old smaller
>> cancel_jmp_buf which doesn't have space for shadow stack pointer.
>>
>
> Any comments?
>

I will check it in next Monday.

-- 
H.J.

^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: [PATCH 1/2] Linux/x86: Update cancel_jmp_buf to match __jmp_buf_tag [BZ #22563]
  2017-12-08  2:25                 ` H.J. Lu
  2017-12-14 13:06                   ` H.J. Lu
@ 2017-12-18 10:25                   ` Florian Weimer
  2017-12-18 11:42                     ` H.J. Lu
  1 sibling, 1 reply; 63+ messages in thread
From: Florian Weimer @ 2017-12-18 10:25 UTC (permalink / raw)
  To: H.J. Lu; +Cc: GNU C Library

[-- Attachment #1: Type: text/plain, Size: 2289 bytes --]

On 12/08/2017 03:25 AM, H.J. Lu wrote:
> Here is call stack during stack unwind:
> 
> (gdb) bt

(snip)

> To unwind shadow stack, we need to save shadow stack pointer in
> __cancel_buf.   This updated patch adds bits/types/__cancel_jmp_buf_tag.h
> to define struct __cancel_jmp_buf_tag so that Linux/x86 can add saved_mask
> to __cancel_jmp_buf.   We will check if shadow stack is enabled before saving
> and restoring shadow stack pointer so that it works with the old smaller
> cancel_jmp_buf which doesn't have space for shadow stack pointer.

I still don't understand why you think you have to reset the shadow stack.

I used this test program:

#include <err.h>
#include <errno.h>
#include <pthread.h>
#include <stdbool.h>
#include <stdio.h>
#include <unistd.h>

__attribute__ ((noinline, noclone, weak))
void
handler1 (void *closure)
{
   printf ("handler1 called\n");
}

__attribute__ ((noinline, noclone, weak))
void
handler2 (void *closure)
{
   printf ("handler2 called\n");
}

__attribute__ ((noinline, noclone, weak))
void
pausefunc (void)
{
   while (true)
     pause ();
}

__attribute__ ((noinline, noclone, weak))
void
handlerfunc (void)
{
   pthread_cleanup_push (handler2, NULL);
   pausefunc ();
   pthread_cleanup_pop (1);
}


__attribute__ ((noinline, noclone, weak))
void *
threadfunc (void *closure)
{
   pthread_cleanup_push (handler1, NULL);
   handlerfunc ();
   pthread_cleanup_pop (0);
   return NULL;
}

int
main (void)
{
   pthread_t thr;
   int ret = pthread_create (&thr, NULL, threadfunc, NULL);
   if (ret != 0)
     {
       errno = ret;
       err (1, "pthread_create");
     }

   ret = pthread_cancel (thr);
   if (ret != 0)
     {
       errno = ret;
       err (1, "pthread_cancel");
     }

   void *result;
   ret = pthread_join (thr, &result);
   if (ret != 0)
     {
       errno = ret;
       err (1, "pthread_join");
     }
   if (result != PTHREAD_CANCELED)
     errx (1, "pthread_join did not return PTHREAD_CANCEL, but %p", result);

   return 0;
}

See the attached GDB log.  As you can see, I set breakpoints on all 
pre-existing RET instructions on the call stack (which would be 
protected by the shadow stack with CET).  None of the RET instructions 
actually execute, ergo we do not have to restore the shadow stack.

Thanks,
Florian

[-- Attachment #2: gdblog.txt --]
[-- Type: text/plain, Size: 23098 bytes --]

gdb ./simple-cancel 
GNU gdb (GDB) Fedora 8.0.1-33.fc26
Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./simple-cancel...done.
(gdb) r
Starting program: /home/fweimer/tmp/simple-cancel 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
[New Thread 0x7ffff77e1700 (LWP 12256)]
handler2 called
handler1 called
[Thread 0x7ffff77e1700 (LWP 12256) exited]
[Inferior 1 (process 12252) exited normally]
Missing separate debuginfos, use: dnf debuginfo-install libgcc-7.2.1-2.fc26.x86_64
(gdb) break sigcancel_handler
Breakpoint 1 at 0x7ffff7bbc960: file nptl-init.c, line 187.
(gdb) r
Starting program: /home/fweimer/tmp/simple-cancel 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
[New Thread 0x7ffff77e1700 (LWP 12258)]
[Switching to Thread 0x7ffff77e1700 (LWP 12258)]

Thread 2 "simple-cancel" hit Breakpoint 1, sigcancel_handler (sig=32, si=0x7ffff77e09b0, ctx=0x7ffff77e0880)
    at nptl-init.c:187
187	  if (sig != SIGCANCEL
(gdb) bt
#0  sigcancel_handler (sig=32, si=0x7ffff77e09b0, ctx=0x7ffff77e0880) at nptl-init.c:187
#1  <signal handler called>
#2  0x00007ffff7bc89ed in pause () at ../sysdeps/unix/syscall-template.S:84
#3  0x000000000040098d in pausefunc () at simple-cancel.c:27
#4  0x00000000004009af in handlerfunc () at simple-cancel.c:35
#5  0x00000000004009ff in threadfunc (closure=<optimized out>) at simple-cancel.c:45
#6  0x00007ffff7bbe36d in start_thread (arg=0x7ffff77e1700) at pthread_create.c:456
#7  0x00007ffff78f2e1f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:97
(gdb) up
#1  <signal handler called>
(gdb) down
#0  sigcancel_handler (sig=32, si=0x7ffff77e09b0, ctx=0x7ffff77e0880) at nptl-init.c:187
187	  if (sig != SIGCANCEL
(gdb) disas
Dump of assembler code for function sigcancel_handler:
=> 0x00007ffff7bbc960 <+0>:	cmp    $0x20,%edi
   0x00007ffff7bbc963 <+3>:	je     0x7ffff7bbc970 <sigcancel_handler+16>
   0x00007ffff7bbc965 <+5>:	repz retq 
   0x00007ffff7bbc967 <+7>:	nopw   0x0(%rax,%rax,1)
   0x00007ffff7bbc970 <+16>:	push   %rbp
   0x00007ffff7bbc971 <+17>:	push   %rbx
   0x00007ffff7bbc972 <+18>:	mov    %rsi,%rbx
   0x00007ffff7bbc975 <+21>:	sub    $0x8,%rsp
   0x00007ffff7bbc979 <+25>:	mov    0x10(%rsi),%ebp
   0x00007ffff7bbc97c <+28>:	callq  0x7ffff7bbc670
   0x00007ffff7bbc981 <+33>:	cmp    %eax,%ebp
   0x00007ffff7bbc983 <+35>:	je     0x7ffff7bbc990 <sigcancel_handler+48>
   0x00007ffff7bbc985 <+37>:	add    $0x8,%rsp
   0x00007ffff7bbc989 <+41>:	pop    %rbx
   0x00007ffff7bbc98a <+42>:	pop    %rbp
   0x00007ffff7bbc98b <+43>:	retq   
   0x00007ffff7bbc98c <+44>:	nopl   0x0(%rax)
   0x00007ffff7bbc990 <+48>:	cmpl   $0xfffffffa,0x8(%rbx)
   0x00007ffff7bbc994 <+52>:	jne    0x7ffff7bbc985 <sigcancel_handler+37>
   0x00007ffff7bbc996 <+54>:	mov    %fs:0x308,%edx
   0x00007ffff7bbc99e <+62>:	jmp    0x7ffff7bbc9b7 <sigcancel_handler+87>
   0x00007ffff7bbc9a0 <+64>:	test   $0x10,%dl
   0x00007ffff7bbc9a3 <+67>:	jne    0x7ffff7bbc985 <sigcancel_handler+37>
   0x00007ffff7bbc9a5 <+69>:	mov    %edx,%eax
   0x00007ffff7bbc9a7 <+71>:	lock cmpxchg %ecx,%fs:0x308
   0x00007ffff7bbc9b1 <+81>:	cmp    %eax,%edx
   0x00007ffff7bbc9b3 <+83>:	je     0x7ffff7bbc9c8 <sigcancel_handler+104>
   0x00007ffff7bbc9b5 <+85>:	mov    %eax,%edx
   0x00007ffff7bbc9b7 <+87>:	mov    %edx,%ecx
   0x00007ffff7bbc9b9 <+89>:	or     $0xc,%ecx
   0x00007ffff7bbc9bc <+92>:	cmp    %ecx,%edx
   0x00007ffff7bbc9be <+94>:	jne    0x7ffff7bbc9a0 <sigcancel_handler+64>
   0x00007ffff7bbc9c0 <+96>:	jmp    0x7ffff7bbc985 <sigcancel_handler+37>
   0x00007ffff7bbc9c2 <+98>:	nopw   0x0(%rax,%rax,1)
   0x00007ffff7bbc9c8 <+104>:	movq   $0xffffffffffffffff,%fs:0x630
   0x00007ffff7bbc9d5 <+117>:	and    $0x2,%edx
   0x00007ffff7bbc9d8 <+120>:	je     0x7ffff7bbc985 <sigcancel_handler+37>
   0x00007ffff7bbc9da <+122>:	lock orl $0x10,%fs:0x308
   0x00007ffff7bbc9e4 <+132>:	mov    %fs:0x300,%rdi
   0x00007ffff7bbc9ed <+141>:	callq  0x7ffff7bc7e60 <__GI___pthread_unwind>
End of assembler dump.
(gdb) break *0x00007ffff7bbc965
Breakpoint 2 at 0x7ffff7bbc965: file nptl-init.c, line 187.
(gdb) break *0x00007ffff7bbc98b
Breakpoint 3 at 0x7ffff7bbc98b: file nptl-init.c, line 223.
(gdb) up
#1  <signal handler called>
(gdb) disas
Dump of assembler code for function __restore_rt:
=> 0x00007ffff7bc93b0 <+0>:	mov    $0xf,%rax
   0x00007ffff7bc93b7 <+7>:	syscall 
   0x00007ffff7bc93b9 <+9>:	nopl   0x0(%rax)
End of assembler dump.
(gdb) up
#2  0x00007ffff7bc89ed in pause () at ../sysdeps/unix/syscall-template.S:84
84	T_PSEUDO (SYSCALL_SYMBOL, SYSCALL_NAME, SYSCALL_NARGS)
(gdb) disas
Dump of assembler code for function pause:
   0x00007ffff7bc89c0 <+0>:	cmpl   $0x0,0x20c7b9(%rip)        # 0x7ffff7dd5180 <__pthread_multiple_threads>
   0x00007ffff7bc89c7 <+7>:	jne    0x7ffff7bc89d9 <pause+25>
   0x00007ffff7bc89c9 <+0>:	mov    $0x22,%eax
   0x00007ffff7bc89ce <+5>:	syscall 
   0x00007ffff7bc89d0 <+7>:	cmp    $0xfffffffffffff001,%rax
   0x00007ffff7bc89d6 <+13>:	jae    0x7ffff7bc8a09 <pause+73>
   0x00007ffff7bc89d8 <+15>:	retq   
   0x00007ffff7bc89d9 <+25>:	sub    $0x8,%rsp
   0x00007ffff7bc89dd <+29>:	callq  0x7ffff7bc7f90 <__pthread_enable_asynccancel>
   0x00007ffff7bc89e2 <+34>:	mov    %rax,(%rsp)
   0x00007ffff7bc89e6 <+38>:	mov    $0x22,%eax
   0x00007ffff7bc89eb <+43>:	syscall 
=> 0x00007ffff7bc89ed <+45>:	mov    (%rsp),%rdi
   0x00007ffff7bc89f1 <+49>:	mov    %rax,%rdx
   0x00007ffff7bc89f4 <+52>:	callq  0x7ffff7bc7ff0 <__pthread_disable_asynccancel>
   0x00007ffff7bc89f9 <+57>:	mov    %rdx,%rax
   0x00007ffff7bc89fc <+60>:	add    $0x8,%rsp
   0x00007ffff7bc8a00 <+64>:	cmp    $0xfffffffffffff001,%rax
   0x00007ffff7bc8a06 <+70>:	jae    0x7ffff7bc8a09 <pause+73>
   0x00007ffff7bc8a08 <+72>:	retq   
   0x00007ffff7bc8a09 <+73>:	mov    0x208370(%rip),%rcx        # 0x7ffff7dd0d80
   0x00007ffff7bc8a10 <+80>:	neg    %eax
   0x00007ffff7bc8a12 <+82>:	mov    %eax,%fs:(%rcx)
   0x00007ffff7bc8a15 <+85>:	or     $0xffffffffffffffff,%rax
   0x00007ffff7bc8a19 <+89>:	retq   
End of assembler dump.
(gdb) break *0x00007ffff7bc89d8
Breakpoint 4 at 0x7ffff7bc89d8: file ../sysdeps/unix/syscall-template.S, line 84.
(gdb) break *0x00007ffff7bc8a08
Breakpoint 5 at 0x7ffff7bc8a08: file ../sysdeps/unix/syscall-template.S, line 85.
(gdb) break *0x00007ffff7bc8a19
Breakpoint 6 at 0x7ffff7bc8a19: file ../sysdeps/unix/syscall-template.S, line 86.
(gdb) up
#3  0x000000000040098d in pausefunc () at simple-cancel.c:27
27	    pause ();
(gdb) disas
Dump of assembler code for function pausefunc:
   0x0000000000400980 <+0>:	sub    $0x8,%rsp
   0x0000000000400984 <+4>:	nopl   0x0(%rax)
   0x0000000000400988 <+8>:	callq  0x400780 <pause@plt>
=> 0x000000000040098d <+13>:	jmp    0x400988 <pausefunc+8>
End of assembler dump.
(gdb) up
#4  0x00000000004009af in handlerfunc () at simple-cancel.c:35
35	  pausefunc ();
(gdb) disas
Dump of assembler code for function handlerfunc:
   0x0000000000400990 <+0>:	sub    $0x78,%rsp
   0x0000000000400994 <+4>:	xor    %esi,%esi
   0x0000000000400996 <+6>:	mov    %rsp,%rdi
   0x0000000000400999 <+9>:	callq  0x4007c0 <__sigsetjmp@plt>
   0x000000000040099e <+14>:	test   %eax,%eax
   0x00000000004009a0 <+16>:	jne    0x4009c8 <handlerfunc+56>
   0x00000000004009a2 <+18>:	mov    %rsp,%rdi
   0x00000000004009a5 <+21>:	callq  0x400750 <__pthread_register_cancel@plt>
   0x00000000004009aa <+26>:	callq  0x400980 <pausefunc>
=> 0x00000000004009af <+31>:	mov    %rsp,%rdi
   0x00000000004009b2 <+34>:	callq  0x400770 <__pthread_unregister_cancel@plt>
   0x00000000004009b7 <+39>:	xor    %edi,%edi
   0x00000000004009b9 <+41>:	callq  0x400970 <handler2>
   0x00000000004009be <+46>:	add    $0x78,%rsp
   0x00000000004009c2 <+50>:	retq   
   0x00000000004009c3 <+51>:	nopl   0x0(%rax,%rax,1)
   0x00000000004009c8 <+56>:	xor    %edi,%edi
   0x00000000004009ca <+58>:	callq  0x400970 <handler2>
   0x00000000004009cf <+63>:	mov    %rsp,%rdi
   0x00000000004009d2 <+66>:	callq  0x4007b0 <__pthread_unwind_next@plt>
End of assembler dump.
(gdb) break *0x00000000004009c2
Breakpoint 7 at 0x4009c2: file simple-cancel.c, line 37.
(gdb) up
#5  0x00000000004009ff in threadfunc (closure=<optimized out>) at simple-cancel.c:45
45	  handlerfunc ();
(gdb) disas
Dump of assembler code for function threadfunc:
   0x00000000004009e0 <+0>:	sub    $0x78,%rsp
   0x00000000004009e4 <+4>:	xor    %esi,%esi
   0x00000000004009e6 <+6>:	mov    %rsp,%rdi
   0x00000000004009e9 <+9>:	callq  0x4007c0 <__sigsetjmp@plt>
   0x00000000004009ee <+14>:	test   %eax,%eax
   0x00000000004009f0 <+16>:	jne    0x400a10 <threadfunc+48>
   0x00000000004009f2 <+18>:	mov    %rsp,%rdi
   0x00000000004009f5 <+21>:	callq  0x400750 <__pthread_register_cancel@plt>
   0x00000000004009fa <+26>:	callq  0x400990 <handlerfunc>
=> 0x00000000004009ff <+31>:	mov    %rsp,%rdi
   0x0000000000400a02 <+34>:	callq  0x400770 <__pthread_unregister_cancel@plt>
   0x0000000000400a07 <+39>:	xor    %eax,%eax
   0x0000000000400a09 <+41>:	add    $0x78,%rsp
   0x0000000000400a0d <+45>:	retq   
   0x0000000000400a0e <+46>:	xchg   %ax,%ax
   0x0000000000400a10 <+48>:	xor    %edi,%edi
   0x0000000000400a12 <+50>:	callq  0x400960 <handler1>
   0x0000000000400a17 <+55>:	mov    %rsp,%rdi
   0x0000000000400a1a <+58>:	callq  0x4007b0 <__pthread_unwind_next@plt>
End of assembler dump.
(gdb) break *0x0000000000400a0d
Breakpoint 8 at 0x400a0d: file simple-cancel.c, line 48.
(gdb) up
#6  0x00007ffff7bbe36d in start_thread (arg=0x7ffff77e1700) at pthread_create.c:456
456	      THREAD_SETMEM (pd, result, CALL_THREAD_FCT (pd));
(gdb) disas
Dump of assembler code for function start_thread:
   0x00007ffff7bbe290 <+0>:	push   %rbx
   0x00007ffff7bbe291 <+1>:	mov    %rdi,%rbx
   0x00007ffff7bbe294 <+4>:	sub    $0xa0,%rsp
   0x00007ffff7bbe29b <+11>:	mov    %rdi,0x8(%rsp)
   0x00007ffff7bbe2a0 <+16>:	mov    %fs:0x28,%rax
   0x00007ffff7bbe2a9 <+25>:	mov    %rax,0x98(%rsp)
   0x00007ffff7bbe2b1 <+33>:	xor    %eax,%eax
   0x00007ffff7bbe2b3 <+35>:	rdtsc  
   0x00007ffff7bbe2b5 <+37>:	shl    $0x20,%rdx
   0x00007ffff7bbe2b9 <+41>:	mov    %eax,%eax
   0x00007ffff7bbe2bb <+43>:	or     %rax,%rdx
   0x00007ffff7bbe2be <+46>:	mov    %rdx,%fs:0x620
   0x00007ffff7bbe2c7 <+55>:	mov    0x212ada(%rip),%rax        # 0x7ffff7dd0da8
   0x00007ffff7bbe2ce <+62>:	lea    0x6b8(%rdi),%rdx
   0x00007ffff7bbe2d5 <+69>:	mov    %rdx,%fs:(%rax)
   0x00007ffff7bbe2d9 <+73>:	callq  0x7ffff7bbc780
   0x00007ffff7bbe2de <+78>:	xor    %eax,%eax
   0x00007ffff7bbe2e0 <+80>:	xchg   %eax,0x61c(%rbx)
   0x00007ffff7bbe2e6 <+86>:	cmp    $0xfffffffe,%eax
   0x00007ffff7bbe2e9 <+89>:	je     0x7ffff7bbe46b <start_thread+475>
   0x00007ffff7bbe2ef <+95>:	mov    0x8(%rsp),%rbx
   0x00007ffff7bbe2f4 <+100>:	mov    $0x18,%esi
   0x00007ffff7bbe2f9 <+105>:	mov    $0x111,%eax
   0x00007ffff7bbe2fe <+110>:	lea    0x2e0(%rbx),%rdi
   0x00007ffff7bbe305 <+117>:	syscall 
   0x00007ffff7bbe307 <+119>:	testb  $0x4,0x614(%rbx)
   0x00007ffff7bbe30e <+126>:	jne    0x7ffff7bbe432 <start_thread+418>
   0x00007ffff7bbe314 <+132>:	lea    0x10(%rsp),%rdi
   0x00007ffff7bbe319 <+137>:	movq   $0x0,0x58(%rsp)
   0x00007ffff7bbe322 <+146>:	movq   $0x0,0x60(%rsp)
   0x00007ffff7bbe32b <+155>:	callq  0x7ffff7bbc6e0
   0x00007ffff7bbe330 <+160>:	test   %eax,%eax
   0x00007ffff7bbe332 <+162>:	mov    %eax,%ebx
   0x00007ffff7bbe334 <+164>:	jne    0x7ffff7bbe376 <start_thread+230>
   0x00007ffff7bbe336 <+166>:	lea    0x10(%rsp),%rax
   0x00007ffff7bbe33b <+171>:	mov    %rax,%fs:0x300
   0x00007ffff7bbe344 <+180>:	mov    0x8(%rsp),%rax
   0x00007ffff7bbe349 <+185>:	cmpb   $0x0,0x613(%rax)
   0x00007ffff7bbe350 <+192>:	jne    0x7ffff7bbe4d4 <start_thread+580>
   0x00007ffff7bbe356 <+198>:	mov    0x8(%rsp),%rax
   0x00007ffff7bbe35b <+203>:	nop
   0x00007ffff7bbe35c <+204>:	mov    %fs:0x648,%rdi
   0x00007ffff7bbe365 <+213>:	callq  *%fs:0x640
=> 0x00007ffff7bbe36d <+221>:	mov    %rax,%fs:0x630
   0x00007ffff7bbe376 <+230>:	callq  0x7ffff7bbc6d0
   0x00007ffff7bbe37b <+235>:	xor    %eax,%eax
   0x00007ffff7bbe37d <+237>:	mov    %fs:0x610,%al
   0x00007ffff7bbe385 <+245>:	test   %al,%al
   0x00007ffff7bbe387 <+247>:	jne    0x7ffff7bbe428 <start_thread+408>
   0x00007ffff7bbe38d <+253>:	callq  0x7ffff7bbc710
   0x00007ffff7bbe392 <+258>:	lock decl 0x212c87(%rip)        # 0x7ffff7dd1020 <__nptl_nthreads>
   0x00007ffff7bbe399 <+265>:	sete   %al
   0x00007ffff7bbe39c <+268>:	test   %al,%al
   0x00007ffff7bbe39e <+270>:	jne    0x7ffff7bbe5cd <start_thread+829>
   0x00007ffff7bbe3a4 <+276>:	mov    0x8(%rsp),%rax
   0x00007ffff7bbe3a9 <+281>:	cmpb   $0x0,0x611(%rax)
   0x00007ffff7bbe3b0 <+288>:	jne    0x7ffff7bbe59f <start_thread+783>
   0x00007ffff7bbe3b6 <+294>:	mov    0x8(%rsp),%rbx
   0x00007ffff7bbe3bb <+299>:	lock orl $0x10,0x308(%rbx)
   0x00007ffff7bbe3c3 <+307>:	callq  0x7ffff7bbc758
   0x00007ffff7bbe3c8 <+312>:	mov    0x690(%rbx),%rdi
   0x00007ffff7bbe3cf <+319>:	neg    %eax
   0x00007ffff7bbe3d1 <+321>:	mov    %rsp,%rdx
   0x00007ffff7bbe3d4 <+324>:	cltq   
   0x00007ffff7bbe3d6 <+326>:	sub    %rdi,%rdx
   0x00007ffff7bbe3d9 <+329>:	and    %rdx,%rax
   0x00007ffff7bbe3dc <+332>:	cmp    %rax,0x698(%rbx)
   0x00007ffff7bbe3e3 <+339>:	jbe    0x7ffff7bbe4b5 <start_thread+549>
   0x00007ffff7bbe3e9 <+345>:	cmp    $0x4000,%rax
   0x00007ffff7bbe3ef <+351>:	ja     0x7ffff7bbe617 <start_thread+903>
   0x00007ffff7bbe3f5 <+357>:	mov    0x8(%rsp),%rax
   0x00007ffff7bbe3fa <+362>:	cmp    %rax,0x628(%rax)
   0x00007ffff7bbe401 <+369>:	je     0x7ffff7bbe608 <start_thread+888>
   0x00007ffff7bbe407 <+375>:	mov    0x8(%rsp),%rax
   0x00007ffff7bbe40c <+380>:	testb  $0x40,0x308(%rax)
   0x00007ffff7bbe413 <+387>:	jne    0x7ffff7bbe53a <start_thread+682>
   0x00007ffff7bbe419 <+393>:	mov    $0x3c,%edx
   0x00007ffff7bbe41e <+398>:	xchg   %ax,%ax
   0x00007ffff7bbe420 <+400>:	xor    %edi,%edi
   0x00007ffff7bbe422 <+402>:	mov    %edx,%eax
   0x00007ffff7bbe424 <+404>:	syscall 
   0x00007ffff7bbe426 <+406>:	jmp    0x7ffff7bbe420 <start_thread+400>
   0x00007ffff7bbe428 <+408>:	callq  0x7ffff7bbd020 <__nptl_deallocate_tsd>
   0x00007ffff7bbe42d <+413>:	jmpq   0x7ffff7bbe38d <start_thread+253>
   0x00007ffff7bbe432 <+418>:	lea    0x18(%rsp),%rdx
   0x00007ffff7bbe437 <+423>:	xor    %eax,%eax
   0x00007ffff7bbe439 <+425>:	mov    $0x1e,%ecx
   0x00007ffff7bbe43e <+430>:	lea    0x10(%rsp),%rsi
   0x00007ffff7bbe443 <+435>:	mov    $0x8,%r10d
   0x00007ffff7bbe449 <+441>:	mov    %rdx,%rdi
   0x00007ffff7bbe44c <+444>:	xor    %edx,%edx
   0x00007ffff7bbe44e <+446>:	rep stos %eax,%es:(%rdi)
   0x00007ffff7bbe450 <+448>:	mov    $0x80000000,%eax
   0x00007ffff7bbe455 <+453>:	mov    $0x1,%edi
   0x00007ffff7bbe45a <+458>:	mov    %rax,0x10(%rsp)
   0x00007ffff7bbe45f <+463>:	mov    $0xe,%eax
   0x00007ffff7bbe464 <+468>:	syscall 
   0x00007ffff7bbe466 <+470>:	jmpq   0x7ffff7bbe314 <start_thread+132>
   0x00007ffff7bbe46b <+475>:	mov    0x8(%rsp),%rax
   0x00007ffff7bbe470 <+480>:	xor    %r10d,%r10d
   0x00007ffff7bbe473 <+483>:	mov    $0x1,%edx
   0x00007ffff7bbe478 <+488>:	mov    $0x81,%esi
   0x00007ffff7bbe47d <+493>:	lea    0x61c(%rax),%rdi
   0x00007ffff7bbe484 <+500>:	mov    $0xca,%eax
   0x00007ffff7bbe489 <+505>:	syscall 
   0x00007ffff7bbe48b <+507>:	cmp    $0xfffffffffffff000,%rax
   0x00007ffff7bbe491 <+513>:	jbe    0x7ffff7bbe2ef <start_thread+95>
   0x00007ffff7bbe497 <+519>:	cmp    $0xffffffea,%eax
   0x00007ffff7bbe49a <+522>:	je     0x7ffff7bbe2ef <start_thread+95>
   0x00007ffff7bbe4a0 <+528>:	cmp    $0xfffffff2,%eax
   0x00007ffff7bbe4a3 <+531>:	je     0x7ffff7bbe2ef <start_thread+95>
   0x00007ffff7bbe4a9 <+537>:	lea    0xc770(%rip),%rdi        # 0x7ffff7bcac20
   0x00007ffff7bbe4b0 <+544>:	callq  0x7ffff7bbc638
   0x00007ffff7bbe4b5 <+549>:	lea    0xc914(%rip),%rcx        # 0x7ffff7bcadd0 <__PRETTY_FUNCTION__.11908>
   0x00007ffff7bbe4bc <+556>:	lea    0xc962(%rip),%rsi        # 0x7ffff7bcae25
   0x00007ffff7bbe4c3 <+563>:	lea    0xc8b6(%rip),%rdi        # 0x7ffff7bcad80
   0x00007ffff7bbe4ca <+570>:	mov    $0x22a,%edx
   0x00007ffff7bbe4cf <+575>:	callq  0x7ffff7bbc6a0
   0x00007ffff7bbe4d4 <+580>:	callq  0x7ffff7bc7f90 <__pthread_enable_asynccancel>
   0x00007ffff7bbe4d9 <+585>:	mov    $0x1,%esi
   0x00007ffff7bbe4de <+590>:	mov    %eax,%edx
   0x00007ffff7bbe4e0 <+592>:	mov    %ebx,%eax
   0x00007ffff7bbe4e2 <+594>:	mov    0x8(%rsp),%rbx
   0x00007ffff7bbe4e7 <+599>:	lock cmpxchg %esi,0x618(%rbx)
   0x00007ffff7bbe4ef <+607>:	je     0x7ffff7bbe50b <start_thread+635>
   0x00007ffff7bbe4f1 <+609>:	lea    0x618(%rbx),%rdi
   0x00007ffff7bbe4f8 <+616>:	sub    $0x80,%rsp
   0x00007ffff7bbe4ff <+623>:	callq  0x7ffff7bc8050 <__lll_lock_wait_private>
   0x00007ffff7bbe504 <+628>:	add    $0x80,%rsp
   0x00007ffff7bbe50b <+635>:	lock decl 0x618(%rbx)
   0x00007ffff7bbe512 <+642>:	je     0x7ffff7bbe52e <start_thread+670>
   0x00007ffff7bbe514 <+644>:	lea    0x618(%rbx),%rdi
   0x00007ffff7bbe51b <+651>:	sub    $0x80,%rsp
   0x00007ffff7bbe522 <+658>:	callq  0x7ffff7bc8100 <__lll_unlock_wake_private>
   0x00007ffff7bbe527 <+663>:	add    $0x80,%rsp
   0x00007ffff7bbe52e <+670>:	mov    %edx,%edi
   0x00007ffff7bbe530 <+672>:	callq  0x7ffff7bc7ff0 <__pthread_disable_asynccancel>
   0x00007ffff7bbe535 <+677>:	jmpq   0x7ffff7bbe356 <start_thread+198>
   0x00007ffff7bbe53a <+682>:	lea    0x61c(%rax),%rbx
   0x00007ffff7bbe541 <+689>:	mov    $0xca,%r9d
   0x00007ffff7bbe547 <+695>:	mov    $0x1,%r8d
   0x00007ffff7bbe54d <+701>:	jmp    0x7ffff7bbe561 <start_thread+721>
   0x00007ffff7bbe54f <+703>:	mov    0x8(%rsp),%rax
   0x00007ffff7bbe554 <+708>:	testb  $0x40,0x308(%rax)
   0x00007ffff7bbe55b <+715>:	je     0x7ffff7bbe62d <start_thread+925>
   0x00007ffff7bbe561 <+721>:	xor    %r10d,%r10d
   0x00007ffff7bbe564 <+724>:	xor    %edx,%edx
   0x00007ffff7bbe566 <+726>:	mov    $0x80,%esi
   0x00007ffff7bbe56b <+731>:	mov    %rbx,%rdi
   0x00007ffff7bbe56e <+734>:	mov    %r9d,%eax
   0x00007ffff7bbe571 <+737>:	syscall 
   0x00007ffff7bbe573 <+739>:	cmp    $0xfffffffffffff000,%rax
   0x00007ffff7bbe579 <+745>:	jbe    0x7ffff7bbe54f <start_thread+703>
   0x00007ffff7bbe57b <+747>:	add    $0xb,%eax
   0x00007ffff7bbe57e <+750>:	cmp    $0xb,%eax
   0x00007ffff7bbe581 <+753>:	ja     0x7ffff7bbe4a9 <start_thread+537>
   0x00007ffff7bbe587 <+759>:	mov    %eax,%ecx
   0x00007ffff7bbe589 <+761>:	mov    %r8,%rsi
   0x00007ffff7bbe58c <+764>:	shl    %cl,%rsi
   0x00007ffff7bbe58f <+767>:	mov    %rsi,%rax
   0x00007ffff7bbe592 <+770>:	test   $0x881,%eax
   0x00007ffff7bbe597 <+775>:	je     0x7ffff7bbe4a9 <start_thread+537>
   0x00007ffff7bbe59d <+781>:	jmp    0x7ffff7bbe54f <start_thread+703>
   0x00007ffff7bbe59f <+783>:	mov    0x8(%rsp),%rcx
   0x00007ffff7bbe5a4 <+788>:	mov    0x216b36(%rip),%eax        # 0x7ffff7dd50e0 <__nptl_threads_events>
   0x00007ffff7bbe5aa <+794>:	or     0x650(%rcx),%eax
   0x00007ffff7bbe5b0 <+800>:	test   $0x1,%ah
   0x00007ffff7bbe5b3 <+803>:	je     0x7ffff7bbe3b6 <start_thread+294>
   0x00007ffff7bbe5b9 <+809>:	cmpq   $0x0,0x668(%rcx)
   0x00007ffff7bbe5c1 <+817>:	je     0x7ffff7bbe5d4 <start_thread+836>
   0x00007ffff7bbe5c3 <+819>:	callq  0x7ffff7bbced0 <__nptl_death_event>
   0x00007ffff7bbe5c8 <+824>:	jmpq   0x7ffff7bbe3b6 <start_thread+294>
   0x00007ffff7bbe5cd <+829>:	xor    %edi,%edi
   0x00007ffff7bbe5cf <+831>:	callq  0x7ffff7bbc810
   0x00007ffff7bbe5d4 <+836>:	mov    %rcx,%rax
   0x00007ffff7bbe5d7 <+839>:	movl   $0x9,0x658(%rcx)
   0x00007ffff7bbe5e1 <+849>:	mov    %rcx,0x660(%rax)
   0x00007ffff7bbe5e8 <+856>:	mov    0x216ae9(%rip),%rax        # 0x7ffff7dd50d8 <__nptl_last_event>
   0x00007ffff7bbe5ef <+863>:	mov    0x8(%rsp),%rsi
   0x00007ffff7bbe5f4 <+868>:	mov    %rax,0x668(%rsi)
   0x00007ffff7bbe5fb <+875>:	lock cmpxchg %rsi,0x216ad4(%rip)        # 0x7ffff7dd50d8 <__nptl_last_event>
   0x00007ffff7bbe604 <+884>:	je     0x7ffff7bbe5c3 <start_thread+819>
   0x00007ffff7bbe606 <+886>:	jmp    0x7ffff7bbe5e8 <start_thread+856>
   0x00007ffff7bbe608 <+888>:	mov    0x8(%rsp),%rdi
   0x00007ffff7bbe60d <+893>:	callq  0x7ffff7bbe0a0 <__free_tcb>
   0x00007ffff7bbe612 <+898>:	jmpq   0x7ffff7bbe419 <start_thread+393>
   0x00007ffff7bbe617 <+903>:	lea    -0x4000(%rax),%rsi
   0x00007ffff7bbe61e <+910>:	mov    $0x4,%edx
   0x00007ffff7bbe623 <+915>:	callq  0x7ffff7bbc7b8
   0x00007ffff7bbe628 <+920>:	jmpq   0x7ffff7bbe3f5 <start_thread+357>
   0x00007ffff7bbe62d <+925>:	movl   $0x0,0x61c(%rax)
   0x00007ffff7bbe637 <+935>:	jmpq   0x7ffff7bbe419 <start_thread+393>
End of assembler dump.
(gdb) up
#7  0x00007ffff78f2e1f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:97
97		call	*%rax
(gdb) disas
Dump of assembler code for function clone:
   0x00007ffff78f2de0 <+0>:	mov    $0xffffffffffffffea,%rax
   0x00007ffff78f2de7 <+7>:	test   %rdi,%rdi
   0x00007ffff78f2dea <+10>:	je     0x7ffff78f2e27 <clone+71>
   0x00007ffff78f2dec <+12>:	test   %rsi,%rsi
   0x00007ffff78f2def <+15>:	je     0x7ffff78f2e27 <clone+71>
   0x00007ffff78f2df1 <+17>:	sub    $0x10,%rsi
   0x00007ffff78f2df5 <+21>:	mov    %rcx,0x8(%rsi)
   0x00007ffff78f2df9 <+25>:	mov    %rdi,(%rsi)
   0x00007ffff78f2dfc <+28>:	mov    %rdx,%rdi
   0x00007ffff78f2dff <+31>:	mov    %r8,%rdx
   0x00007ffff78f2e02 <+34>:	mov    %r9,%r8
   0x00007ffff78f2e05 <+37>:	mov    0x8(%rsp),%r10
   0x00007ffff78f2e0a <+42>:	mov    $0x38,%eax
   0x00007ffff78f2e0f <+47>:	syscall 
   0x00007ffff78f2e11 <+49>:	test   %rax,%rax
   0x00007ffff78f2e14 <+52>:	jl     0x7ffff78f2e27 <clone+71>
   0x00007ffff78f2e16 <+54>:	je     0x7ffff78f2e19 <clone+57>
   0x00007ffff78f2e18 <+56>:	retq   
   0x00007ffff78f2e19 <+57>:	xor    %ebp,%ebp
   0x00007ffff78f2e1b <+59>:	pop    %rax
   0x00007ffff78f2e1c <+60>:	pop    %rdi
   0x00007ffff78f2e1d <+61>:	callq  *%rax
=> 0x00007ffff78f2e1f <+63>:	mov    %rax,%rdi
   0x00007ffff78f2e22 <+66>:	callq  0x7ffff78b6fc0 <__GI__exit>
   0x00007ffff78f2e27 <+71>:	mov    0x2be03a(%rip),%rcx        # 0x7ffff7bb0e68
   0x00007ffff78f2e2e <+78>:	neg    %eax
   0x00007ffff78f2e30 <+80>:	mov    %eax,%fs:(%rcx)
   0x00007ffff78f2e33 <+83>:	or     $0xffffffffffffffff,%rax
   0x00007ffff78f2e37 <+87>:	retq   
End of assembler dump.
(gdb) break *0x00007ffff78f2e37
Breakpoint 9 at 0x7ffff78f2e37: file ../sysdeps/unix/sysv/linux/x86_64/clone.S, line 104.
(gdb) up
Initial frame selected; you cannot go up.
(gdb) c
Continuing.
handler2 called
handler1 called
[Thread 0x7ffff77e1700 (LWP 12258) exited]
[Inferior 1 (process 12257) exited normally]
(gdb) 

^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: [PATCH 1/2] Linux/x86: Update cancel_jmp_buf to match __jmp_buf_tag [BZ #22563]
  2017-12-18 10:25                   ` Florian Weimer
@ 2017-12-18 11:42                     ` H.J. Lu
  2017-12-18 11:49                       ` Florian Weimer
  0 siblings, 1 reply; 63+ messages in thread
From: H.J. Lu @ 2017-12-18 11:42 UTC (permalink / raw)
  To: Florian Weimer; +Cc: GNU C Library

On Mon, Dec 18, 2017 at 2:25 AM, Florian Weimer <fweimer@redhat.com> wrote:
> On 12/08/2017 03:25 AM, H.J. Lu wrote:
>>
>> Here is call stack during stack unwind:
>>
>> (gdb) bt
>
>
> (snip)
>
>> To unwind shadow stack, we need to save shadow stack pointer in
>> __cancel_buf.   This updated patch adds bits/types/__cancel_jmp_buf_tag.h
>> to define struct __cancel_jmp_buf_tag so that Linux/x86 can add saved_mask
>> to __cancel_jmp_buf.   We will check if shadow stack is enabled before
>> saving
>> and restoring shadow stack pointer so that it works with the old smaller
>> cancel_jmp_buf which doesn't have space for shadow stack pointer.
>
>
> I still don't understand why you think you have to reset the shadow stack.
>
> I used this test program:
>
> #include <err.h>
> #include <errno.h>
> #include <pthread.h>
> #include <stdbool.h>
> #include <stdio.h>
> #include <unistd.h>
>
> __attribute__ ((noinline, noclone, weak))
> void
> handler1 (void *closure)
> {
>   printf ("handler1 called\n");
> }
>
> __attribute__ ((noinline, noclone, weak))
> void
> handler2 (void *closure)
> {
>   printf ("handler2 called\n");
> }
>
> __attribute__ ((noinline, noclone, weak))
> void
> pausefunc (void)
> {
>   while (true)
>     pause ();
> }
>
> __attribute__ ((noinline, noclone, weak))
> void
> handlerfunc (void)
> {
>   pthread_cleanup_push (handler2, NULL);
>   pausefunc ();
>   pthread_cleanup_pop (1);
> }
>
>
> __attribute__ ((noinline, noclone, weak))
> void *
> threadfunc (void *closure)
> {
>   pthread_cleanup_push (handler1, NULL);
>   handlerfunc ();
>   pthread_cleanup_pop (0);
>   return NULL;
> }
>
> int
> main (void)
> {
>   pthread_t thr;
>   int ret = pthread_create (&thr, NULL, threadfunc, NULL);
>   if (ret != 0)
>     {
>       errno = ret;
>       err (1, "pthread_create");
>     }
>
>   ret = pthread_cancel (thr);
>   if (ret != 0)
>     {
>       errno = ret;
>       err (1, "pthread_cancel");
>     }
>
>   void *result;
>   ret = pthread_join (thr, &result);
>   if (ret != 0)
>     {
>       errno = ret;
>       err (1, "pthread_join");
>     }
>   if (result != PTHREAD_CANCELED)
>     errx (1, "pthread_join did not return PTHREAD_CANCEL, but %p", result);
>
>   return 0;
> }
>
> See the attached GDB log.  As you can see, I set breakpoints on all
> pre-existing RET instructions on the call stack (which would be protected by
> the shadow stack with CET).  None of the RET instructions actually execute,
> ergo we do not have to restore the shadow stack.
>

Shadow stack is invisible to programs.  Shadow stack instructions are
used to maintain shadow stack, like what my patch does.   Any times
there is a "call" instruction, the return address is pushed onto shadow stack.
In your case,

gdb) r
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /tmp/a.out
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".

Breakpoint 1, main () at x.c:52
52 {
(gdb) ena 2
(gdb) c
Continuing.
[New Thread 0x7ffff77d2700 (LWP 12779)]

Thread 1 "a.out" hit Breakpoint 2, 0x00007ffff780a320 in __sigsetjmp ()
   from /lib64/libc.so.6
(gdb) bt
#0  0x00007ffff780a320 in __sigsetjmp () from /lib64/libc.so.6

We need to save stack stack pointer here in __sigsetjmp,

#1  0x00007ffff7bbd5c0 in start_thread () from /lib64/libpthread.so.0
#2  0x00007ffff78ea88f in clone () from /lib64/libc.so.6
(gdb) dis 2
(gdb) ena 3
(gdb) c
Continuing.
[Switching to Thread 0x7ffff77d2700 (LWP 12779)]

Thread 2 "a.out" hit Breakpoint 3, 0x00007ffff780a410 in __longjmp ()
   from /lib64/libc.so.6
Missing separate debuginfos, use: dnf debuginfo-install
libgcc-7.2.1-4.0.fc27.x86_64
(gdb) bt
#0  0x00007ffff780a410 in __longjmp () from /lib64/libc.so.6

We need to restore shadow stack pointer here so that we can jump back
to the function where __sigsetjmp  is called.

#1  0x00007ffff780a3fb in siglongjmp () from /lib64/libc.so.6
#2  0x00007ffff7bc707d in unwind_stop () from /lib64/libpthread.so.0
#3  0x00007ffff6dcaf2e in ?? () from /lib64/libgcc_s.so.1
#4  0x00007ffff6dcb515 in _Unwind_ForcedUnwind () from /lib64/libgcc_s.so.1
#5  0x00007ffff7bc7180 in __pthread_unwind () from /lib64/libpthread.so.0
#6  0x00007ffff7bbbc82 in sigcancel_handler () from /lib64/libpthread.so.0
#7  <signal handler called>
#8  0x00007ffff7bc8052 in pause () from /lib64/libpthread.so.0
#9  0x000000000040098d in pausefunc () at x.c:27
#10 0x00000000004009af in handlerfunc () at x.c:35
#11 0x00000000004009ff in threadfunc (closure=<optimized out>) at x.c:45
#12 0x00007ffff7bbd5f9 in start_thread () from /lib64/libpthread.so.0
#13 0x00007ffff78ea88f in clone () from /lib64/libc.so.6
(gdb)

As long as there is a call stack, there is a shadow stack if shadow stack is
enabled.

Does it answer your question?

-- 
H.J.

^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: [PATCH 1/2] Linux/x86: Update cancel_jmp_buf to match __jmp_buf_tag [BZ #22563]
  2017-12-18 11:42                     ` H.J. Lu
@ 2017-12-18 11:49                       ` Florian Weimer
  2017-12-18 12:25                         ` H.J. Lu
  0 siblings, 1 reply; 63+ messages in thread
From: Florian Weimer @ 2017-12-18 11:49 UTC (permalink / raw)
  To: H.J. Lu; +Cc: GNU C Library

On 12/18/2017 12:42 PM, H.J. Lu wrote:
> We need to restore shadow stack pointer here so that we can jump back
> to the function where __sigsetjmp  is called.

But neither __sigsetjmp (when called the second time) nor the function 
that calls it return normally during cancellation, so it is still 
completely unclear to me what issue you are observing.

Could you post a backtrace from the CET verification failure, please?

Thanks,
Florian

^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: [PATCH 1/2] Linux/x86: Update cancel_jmp_buf to match __jmp_buf_tag [BZ #22563]
  2017-12-18 11:49                       ` Florian Weimer
@ 2017-12-18 12:25                         ` H.J. Lu
  2017-12-18 12:52                           ` Florian Weimer
  0 siblings, 1 reply; 63+ messages in thread
From: H.J. Lu @ 2017-12-18 12:25 UTC (permalink / raw)
  To: Florian Weimer; +Cc: GNU C Library

On Mon, Dec 18, 2017 at 3:49 AM, Florian Weimer <fweimer@redhat.com> wrote:
> On 12/18/2017 12:42 PM, H.J. Lu wrote:
>>
>> We need to restore shadow stack pointer here so that we can jump back
>> to the function where __sigsetjmp  is called.
>
>
> But neither __sigsetjmp (when called the second time) nor the function that
> calls it return normally during cancellation, so it is still completely
> unclear to me what issue you are observing.
>
> Could you post a backtrace from the CET verification failure, please?
>

Here is your testcase with full debug info:

(gdb) r
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /export/build/gnu/glibc-cet/build-x86_64-linux/nptl/tst-foo
warning: Unable to find libthread_db matching inferior's thread
library, thread debugging will not be available.

Breakpoint 1, main () at tst-foo.c:52
52 {
(gdb) ena 2
(gdb) c
Continuing.
[Switching to LWP 18711]

Thread 2 "tst-foo" hit Breakpoint 2, __sigsetjmp () at
../sysdeps/unix/sysv/linux/x86_64/setjmp.S:26
26 ENTRY (__sigsetjmp)
(gdb) bt
#0  __sigsetjmp () at ../sysdeps/unix/sysv/linux/x86_64/setjmp.S:26
#1  0x0000000000400e15 in threadfunc (closure=<optimized out>) at tst-foo.c:44
#2  0x00007ffff7bbfcde in start_thread (arg=<optimized out>) at
pthread_create.c:463
#3  0x00007ffff78f5f73 in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:95
(gdb) f 1
#1  0x0000000000400e15 in threadfunc (closure=<optimized out>) at tst-foo.c:44
44   pthread_cleanup_push (handler1, NULL);

Here we call __sigsetjmp with cancel_jmp_buf.  There is a shadow stack for
the normal call stack.  We need to save shadow stack pointer so that we can
lonjmp back here later.

(gdb) dis 2
(gdb) ena 3
(gdb) c
Continuing.

Thread 2 "tst-foo" hit Breakpoint 3, __longjmp () at
../sysdeps/unix/sysv/linux/x86_64/__longjmp.S:30
30 ENTRY(__longjmp)
(gdb) bt
#0  __longjmp () at ../sysdeps/unix/sysv/linux/x86_64/__longjmp.S:30

If we don't restore shadow stack pointer, when we jump back to  tst-foo.c:45,
shadow stack won't match call stack when threadfunc () returns.

#1  0x00007ffff7837f5f in __libc_siglongjmp
(env=env@entry=0x7ffff7800ca0, val=val@entry=1) at longjmp.c:39
#2  0x00007ffff7bc899d in unwind_stop (version=<optimized out>,
actions=<optimized out>, exc_class=<optimized out>,
    exc_obj=<optimized out>, context=<optimized out>,
stop_parameter=0x7ffff7800ca0) at unwind.c:94
#3  0x00007ffff6df9b1e in _Unwind_ForcedUnwind_Phase2
(exc=exc@entry=0x7ffff7801d70,
    context=context@entry=0x7ffff7800550,
frames_p=frames_p@entry=0x7ffff7800458)
    at /export/gnu/import/git/sources/gcc/libgcc/unwind.inc:170
#4  0x00007ffff6dfa170 in _Unwind_ForcedUnwind (exc=0x7ffff7801d70,
stop=stop@entry=0x7ffff7bc88e0 <unwind_stop>,
    stop_argument=<optimized out>) at
/export/gnu/import/git/sources/gcc/libgcc/unwind.inc:217
#5  0x00007ffff7bc8a84 in __GI___pthread_unwind (buf=<optimized out>)
at unwind.c:121
#6  0x00007ffff7bbe46a in __do_cancel () at ./pthreadP.h:297
#7  sigcancel_handler (sig=<optimized out>, si=0x7ffff78007f0,
ctx=<optimized out>) at nptl-init.c:216
#8  <signal handler called>
#9  0x00007ffff7bc99b2 in __libc_pause () at
../sysdeps/unix/sysv/linux/pause.c:30
#10 0x0000000000400d95 in pausefunc () at tst-foo.c:27
#11 0x0000000000400dca in handlerfunc () at tst-foo.c:35
#12 0x0000000000400e2a in threadfunc (closure=<optimized out>) at tst-foo.c:45
#13 0x00007ffff7bbfcde in start_thread (arg=<optimized out>) at
pthread_create.c:463
#14 0x00007ffff78f5f73 in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:95
(gdb) f 6
#6  0x00007ffff7bbe46a in __do_cancel () at ./pthreadP.h:297
297   __pthread_unwind ((__pthread_unwind_buf_t *)
(gdb) list
292   struct pthread *self = THREAD_SELF;
293
294   /* Make sure we get no more cancellations.  */
295   THREAD_ATOMIC_BIT_SET (self, cancelhandling, EXITING_BIT);
296
297   __pthread_unwind ((__pthread_unwind_buf_t *)
298     THREAD_GETMEM (self, cleanup_jmp_buf));
299 }
300
301
(gdb)

Does it answer your question?

-- 
H.J.

^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: [PATCH 1/2] Linux/x86: Update cancel_jmp_buf to match __jmp_buf_tag [BZ #22563]
  2017-12-18 12:25                         ` H.J. Lu
@ 2017-12-18 12:52                           ` Florian Weimer
  2017-12-18 13:19                             ` H.J. Lu
  0 siblings, 1 reply; 63+ messages in thread
From: Florian Weimer @ 2017-12-18 12:52 UTC (permalink / raw)
  To: H.J. Lu; +Cc: GNU C Library

On 12/18/2017 01:25 PM, H.J. Lu wrote:
> If we don't restore shadow stack pointer, when we jump back to  tst-foo.c:45,
> shadow stack won't match call stack when threadfunc () returns.

But threadfunc never returns if the thread is canceled, so I'm still as 
puzzled as before.  Sorry.

Florian

^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: [PATCH 1/2] Linux/x86: Update cancel_jmp_buf to match __jmp_buf_tag [BZ #22563]
  2017-12-18 12:52                           ` Florian Weimer
@ 2017-12-18 13:19                             ` H.J. Lu
  2017-12-18 14:13                               ` H.J. Lu
  0 siblings, 1 reply; 63+ messages in thread
From: H.J. Lu @ 2017-12-18 13:19 UTC (permalink / raw)
  To: Florian Weimer; +Cc: GNU C Library

On Mon, Dec 18, 2017 at 4:52 AM, Florian Weimer <fweimer@redhat.com> wrote:
> On 12/18/2017 01:25 PM, H.J. Lu wrote:
>>
>> If we don't restore shadow stack pointer, when we jump back to
>> tst-foo.c:45,
>> shadow stack won't match call stack when threadfunc () returns.
>
>
> But threadfunc never returns if the thread is canceled, so I'm still as
> puzzled as before.  Sorry.

True, threadfunc never returns.  Instead, it lonjmps back to
start_thread:

Thread 2 "tst-foo" hit Breakpoint 2, __longjmp ()
    at ../sysdeps/unix/sysv/linux/x86_64/__longjmp.S:30
30 ENTRY(__longjmp)
(gdb) bt
#0  __longjmp () at ../sysdeps/unix/sysv/linux/x86_64/__longjmp.S:30
#1  0x00007ffff7837f5f in __libc_siglongjmp (env=env@entry=0x7ffff7800eb0,
    val=val@entry=1) at longjmp.c:39
#2  0x00007ffff7bc899d in unwind_stop (version=<optimized out>,
    actions=<optimized out>, exc_class=<optimized out>,
    exc_obj=<optimized out>, context=<optimized out>,
    stop_parameter=0x7ffff7800eb0) at unwind.c:94
#3  0x00007ffff6df9b1e in _Unwind_ForcedUnwind_Phase2 (
    exc=exc@entry=0x7ffff7801d70, context=context@entry=0x7ffff7800c40,
    frames_p=frames_p@entry=0x7ffff7800b48)
    at /export/gnu/import/git/sources/gcc/libgcc/unwind.inc:170
#4  0x00007ffff6dfa170 in _Unwind_ForcedUnwind (exc=0x7ffff7801d70,
    stop=stop@entry=0x7ffff7bc88e0 <unwind_stop>,
    stop_argument=<optimized out>)
    at /export/gnu/import/git/sources/gcc/libgcc/unwind.inc:217
#5  0x00007ffff7bc8a84 in __GI___pthread_unwind (buf=<optimized out>)
    at unwind.c:121
#6  0x00007ffff7bc8aa4 in __GI___pthread_unwind_next (
    buf=buf@entry=0x7ffff7800da0) at unwind.c:136
#7  0x0000000000400e4f in threadfunc (closure=<optimized out>) at tst-foo.c:44
#8  0x00007ffff7bbfcde in start_thread (arg=<optimized out>)
    at pthread_create.c:463
#9  0x00007ffff78f5f73 in clone ()
    at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
(gdb)
104 jmpq *%rdx
(gdb)  next
start_thread (arg=<optimized out>) at pthread_create.c:436
436   if (__glibc_likely (! not_first_call))
(gdb) bt
#0  start_thread (arg=<optimized out>) at pthread_create.c:436
#1  0x00007ffff78f5f73 in clone ()
    at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
(gdb) list
431   unwind_buf.priv.data.prev = NULL;
432   unwind_buf.priv.data.cleanup = NULL;
433
434   int not_first_call;
435   not_first_call = setjmp ((struct __jmp_buf_tag *)
unwind_buf.cancel_jmp_buf);
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

This has to save and restore shadow stack pointer.   Since we only have
one __sigsetjmp and one __longjmp, when shadow stack is enabled, they
have to save and restore shadow stack pointer.  It means cancel_jmp_buf
has to match __jmp_buf_tag.

436   if (__glibc_likely (! not_first_call))
437     {
438       /* Store the new cleanup handler info.  */
439       THREAD_SETMEM (pd, cleanup_jmp_buf, &unwind_buf);
440
(gdb)

Does it answer your question?

-- 
H.J.

^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: [PATCH 1/2] Linux/x86: Update cancel_jmp_buf to match __jmp_buf_tag [BZ #22563]
  2017-12-18 13:19                             ` H.J. Lu
@ 2017-12-18 14:13                               ` H.J. Lu
  2017-12-18 14:45                                 ` Andreas Schwab
  2017-12-18 17:37                                 ` [PATCH 1/2] Linux/x86: Update cancel_jmp_buf to match __jmp_buf_tag [BZ #22563] Joseph Myers
  0 siblings, 2 replies; 63+ messages in thread
From: H.J. Lu @ 2017-12-18 14:13 UTC (permalink / raw)
  To: Florian Weimer; +Cc: GNU C Library

[-- Attachment #1: Type: text/plain, Size: 3676 bytes --]

On Mon, Dec 18, 2017 at 5:19 AM, H.J. Lu <hjl.tools@gmail.com> wrote:
> On Mon, Dec 18, 2017 at 4:52 AM, Florian Weimer <fweimer@redhat.com> wrote:
>> On 12/18/2017 01:25 PM, H.J. Lu wrote:
>>>
>>> If we don't restore shadow stack pointer, when we jump back to
>>> tst-foo.c:45,
>>> shadow stack won't match call stack when threadfunc () returns.
>>
>>
>> But threadfunc never returns if the thread is canceled, so I'm still as
>> puzzled as before.  Sorry.
>
> True, threadfunc never returns.  Instead, it lonjmps back to
> start_thread:
>
> Thread 2 "tst-foo" hit Breakpoint 2, __longjmp ()
>     at ../sysdeps/unix/sysv/linux/x86_64/__longjmp.S:30
> 30 ENTRY(__longjmp)
> (gdb) bt
> #0  __longjmp () at ../sysdeps/unix/sysv/linux/x86_64/__longjmp.S:30
> #1  0x00007ffff7837f5f in __libc_siglongjmp (env=env@entry=0x7ffff7800eb0,
>     val=val@entry=1) at longjmp.c:39
> #2  0x00007ffff7bc899d in unwind_stop (version=<optimized out>,
>     actions=<optimized out>, exc_class=<optimized out>,
>     exc_obj=<optimized out>, context=<optimized out>,
>     stop_parameter=0x7ffff7800eb0) at unwind.c:94
> #3  0x00007ffff6df9b1e in _Unwind_ForcedUnwind_Phase2 (
>     exc=exc@entry=0x7ffff7801d70, context=context@entry=0x7ffff7800c40,
>     frames_p=frames_p@entry=0x7ffff7800b48)
>     at /export/gnu/import/git/sources/gcc/libgcc/unwind.inc:170
> #4  0x00007ffff6dfa170 in _Unwind_ForcedUnwind (exc=0x7ffff7801d70,
>     stop=stop@entry=0x7ffff7bc88e0 <unwind_stop>,
>     stop_argument=<optimized out>)
>     at /export/gnu/import/git/sources/gcc/libgcc/unwind.inc:217
> #5  0x00007ffff7bc8a84 in __GI___pthread_unwind (buf=<optimized out>)
>     at unwind.c:121
> #6  0x00007ffff7bc8aa4 in __GI___pthread_unwind_next (
>     buf=buf@entry=0x7ffff7800da0) at unwind.c:136
> #7  0x0000000000400e4f in threadfunc (closure=<optimized out>) at tst-foo.c:44
> #8  0x00007ffff7bbfcde in start_thread (arg=<optimized out>)
>     at pthread_create.c:463
> #9  0x00007ffff78f5f73 in clone ()
>     at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
> (gdb)
> 104 jmpq *%rdx
> (gdb)  next
> start_thread (arg=<optimized out>) at pthread_create.c:436
> 436   if (__glibc_likely (! not_first_call))
> (gdb) bt
> #0  start_thread (arg=<optimized out>) at pthread_create.c:436
> #1  0x00007ffff78f5f73 in clone ()
>     at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
> (gdb) list
> 431   unwind_buf.priv.data.prev = NULL;
> 432   unwind_buf.priv.data.cleanup = NULL;
> 433
> 434   int not_first_call;
> 435   not_first_call = setjmp ((struct __jmp_buf_tag *)
> unwind_buf.cancel_jmp_buf);
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> This has to save and restore shadow stack pointer.   Since we only have
> one __sigsetjmp and one __longjmp, when shadow stack is enabled, they
> have to save and restore shadow stack pointer.  It means cancel_jmp_buf
> has to match __jmp_buf_tag.
>
> 436   if (__glibc_likely (! not_first_call))
> 437     {
> 438       /* Store the new cleanup handler info.  */
> 439       THREAD_SETMEM (pd, cleanup_jmp_buf, &unwind_buf);
> 440
> (gdb)
>
> Does it answer your question?
>

Here is the updated patch with commit message:

On x86, padding in struct __jmp_buf_tag is used for shadow stack pointer
to support shadow stack in Intel Control-flow Enforcemen Technology.
Since the cancel_jmp_buf array is passed to setjmp and longjmp by
casting it to pointer to struct __jmp_buf_tag, it should be as large
as struct __jmp_buf_tag.  Otherwise when shadow stack is enabled,
setjmp and longjmp will write and read beyond cancel_jmp_buf when saving
and restoring shadow stack pointer.

Does it look OK?

Thanks.

-- 
H.J.

[-- Attachment #2: 0001-Linux-x86-Update-cancel_jmp_buf-to-match-__jmp_buf_t.patch --]
[-- Type: application/octet-stream, Size: 9271 bytes --]

From 01deabe193d420496913936927981de9e90cea57 Mon Sep 17 00:00:00 2001
From: "H.J. Lu" <hjl.tools@gmail.com>
Date: Wed, 6 Dec 2017 15:00:46 -0800
Subject: [PATCH] Linux/x86: Update cancel_jmp_buf to match __jmp_buf_tag [BZ
 #22563]

On x86, padding in struct __jmp_buf_tag is used for shadow stack pointer
to support shadow stack in Intel Control-flow Enforcemen Technology.
Since the cancel_jmp_buf array is passed to setjmp and longjmp by
casting it to pointer to struct __jmp_buf_tag, it should be as large
as struct __jmp_buf_tag.  Otherwise when shadow stack is enabled,
setjmp and longjmp will write and read beyond cancel_jmp_buf when saving
and restoring shadow stack pointer.

This patch adds bits/types/__cancel_jmp_buf_tag.h to define struct
__cancel_jmp_buf_tag so that Linux/x86 can add saved_mask to
cancel_jmp_buf.

	[BZ #22563]
	* bits/types/__cancel_jmp_buf_tag.h: New file.
	* sysdeps/unix/sysv/linux/x86/bits/types/__cancel_jmp_buf_tag.h
	* sysdeps/unix/sysv/linux/x86/pthreaddef.h: Likewise.
	* sysdeps/unix/sysv/linux/x86/nptl/pthreadP.h: Likewise.
	* nptl/Makefile (headers): Add
	bits/types/__cancel_jmp_buf_tag.h.
	* nptl/descr.h [NEED_SAVED_MASK_IN_CANCEL_JMP_BUF]
	(pthread_unwind_buf): Add saved_mask to cancel_jmp_buf.
	* sysdeps/nptl/pthread.h: Include
	<bits/types/__cancel_jmp_buf_tag.h>.
	(__pthread_unwind_buf_t): Use struct __cancel_jmp_buf_tag with
	__cancel_jmp_buf.
---
 bits/types/__cancel_jmp_buf_tag.h                  | 28 +++++++++++++++++
 nptl/Makefile                                      |  3 +-
 nptl/descr.h                                       |  3 ++
 sysdeps/nptl/pthread.h                             |  7 ++---
 .../linux/x86/bits/types/__cancel_jmp_buf_tag.h    | 31 +++++++++++++++++++
 sysdeps/unix/sysv/linux/x86/nptl/pthreadP.h        | 36 ++++++++++++++++++++++
 sysdeps/unix/sysv/linux/x86/pthreaddef.h           | 22 +++++++++++++
 7 files changed, 124 insertions(+), 6 deletions(-)
 create mode 100644 bits/types/__cancel_jmp_buf_tag.h
 create mode 100644 sysdeps/unix/sysv/linux/x86/bits/types/__cancel_jmp_buf_tag.h
 create mode 100644 sysdeps/unix/sysv/linux/x86/nptl/pthreadP.h
 create mode 100644 sysdeps/unix/sysv/linux/x86/pthreaddef.h

diff --git a/bits/types/__cancel_jmp_buf_tag.h b/bits/types/__cancel_jmp_buf_tag.h
new file mode 100644
index 0000000000..c843f44239
--- /dev/null
+++ b/bits/types/__cancel_jmp_buf_tag.h
@@ -0,0 +1,28 @@
+/* Define struct __cancel_jmp_buf_tag.
+   Copyright (C) 2017 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/>.  */
+
+#ifndef ____cancel_jmp_buf_tag_defined
+#define ____cancel_jmp_buf_tag_defined 1
+
+struct __cancel_jmp_buf_tag
+  {
+    __jmp_buf __cancel_jmp_buf;
+    int __mask_was_saved;
+  };
+
+#endif
diff --git a/nptl/Makefile b/nptl/Makefile
index 570a42301c..60d036a1ea 100644
--- a/nptl/Makefile
+++ b/nptl/Makefile
@@ -22,7 +22,8 @@ subdir	:= nptl
 
 include ../Makeconfig
 
-headers := pthread.h semaphore.h bits/semaphore.h
+headers := pthread.h semaphore.h bits/semaphore.h \
+	   bits/types/__cancel_jmp_buf_tag.h
 
 extra-libs := libpthread
 extra-libs-others := $(extra-libs)
diff --git a/nptl/descr.h b/nptl/descr.h
index c83b17b674..fdeb397eab 100644
--- a/nptl/descr.h
+++ b/nptl/descr.h
@@ -65,6 +65,9 @@ struct pthread_unwind_buf
   {
     __jmp_buf jmp_buf;
     int mask_was_saved;
+#ifdef NEED_SAVED_MASK_IN_CANCEL_JMP_BUF
+    __sigset_t saved_mask;
+#endif
   } cancel_jmp_buf[1];
 
   union
diff --git a/sysdeps/nptl/pthread.h b/sysdeps/nptl/pthread.h
index 2b2b386ab3..787ac6e4cd 100644
--- a/sysdeps/nptl/pthread.h
+++ b/sysdeps/nptl/pthread.h
@@ -27,6 +27,7 @@
 #include <bits/setjmp.h>
 #include <bits/wordsize.h>
 #include <bits/types/struct_timespec.h>
+#include <bits/types/__cancel_jmp_buf_tag.h>
 
 
 /* Detach state.  */
@@ -523,11 +524,7 @@ extern void pthread_testcancel (void);
 
 typedef struct
 {
-  struct
-  {
-    __jmp_buf __cancel_jmp_buf;
-    int __mask_was_saved;
-  } __cancel_jmp_buf[1];
+  struct __cancel_jmp_buf_tag __cancel_jmp_buf[1];
   void *__pad[4];
 } __pthread_unwind_buf_t __attribute__ ((__aligned__));
 
diff --git a/sysdeps/unix/sysv/linux/x86/bits/types/__cancel_jmp_buf_tag.h b/sysdeps/unix/sysv/linux/x86/bits/types/__cancel_jmp_buf_tag.h
new file mode 100644
index 0000000000..830a6ec90c
--- /dev/null
+++ b/sysdeps/unix/sysv/linux/x86/bits/types/__cancel_jmp_buf_tag.h
@@ -0,0 +1,31 @@
+/* Define struct __cancel_jmp_buf_tag.
+   Copyright (C) 2017 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/>.  */
+
+#ifndef ____cancel_jmp_buf_tag_defined
+#define ____cancel_jmp_buf_tag_defined 1
+
+#include <bits/types/__sigset_t.h>
+
+struct __cancel_jmp_buf_tag
+  {
+    __jmp_buf __cancel_jmp_buf;
+    int __mask_was_saved;
+    __sigset_t __saved_mask;
+  };
+
+#endif
diff --git a/sysdeps/unix/sysv/linux/x86/nptl/pthreadP.h b/sysdeps/unix/sysv/linux/x86/nptl/pthreadP.h
new file mode 100644
index 0000000000..8c36ba3a5d
--- /dev/null
+++ b/sysdeps/unix/sysv/linux/x86/nptl/pthreadP.h
@@ -0,0 +1,36 @@
+/* Internal pthread header.  Linux/x86 version.
+   Copyright (C) 2017 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/>.  */
+
+#include_next <nptl/pthreadP.h>
+
+#ifndef _PTHREADP_H_X86
+#define _PTHREADP_H_X86 1
+
+extern struct pthread_unwind_buf ____pthread_unwind_buf_private;
+
+_Static_assert (sizeof (____pthread_unwind_buf_private.cancel_jmp_buf)
+		>= sizeof (struct __jmp_buf_tag),
+		"size of cancel_jmp_buf < sizeof __jmp_buf_tag");
+
+extern __pthread_unwind_buf_t ____pthread_unwind_buf;
+
+_Static_assert (sizeof (____pthread_unwind_buf.__cancel_jmp_buf)
+		>= sizeof (struct __jmp_buf_tag),
+		"size of __cancel_jmp_buf < sizeof __jmp_buf_tag");
+
+#endif
diff --git a/sysdeps/unix/sysv/linux/x86/pthreaddef.h b/sysdeps/unix/sysv/linux/x86/pthreaddef.h
new file mode 100644
index 0000000000..89d19d60a1
--- /dev/null
+++ b/sysdeps/unix/sysv/linux/x86/pthreaddef.h
@@ -0,0 +1,22 @@
+/* Pthread macros.  Linux/x86 version.
+   Copyright (C) 2017 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/>.  */
+
+#include_next <pthreaddef.h>
+
+/* Need saved_mask in cancel_jmp_buf.  */
+#define NEED_SAVED_MASK_IN_CANCEL_JMP_BUF 1
-- 
2.14.3


^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: [PATCH 1/2] Linux/x86: Update cancel_jmp_buf to match __jmp_buf_tag [BZ #22563]
  2017-12-18 14:13                               ` H.J. Lu
@ 2017-12-18 14:45                                 ` Andreas Schwab
  2017-12-18 14:48                                   ` H.J. Lu
  2017-12-18 17:37                                 ` [PATCH 1/2] Linux/x86: Update cancel_jmp_buf to match __jmp_buf_tag [BZ #22563] Joseph Myers
  1 sibling, 1 reply; 63+ messages in thread
From: Andreas Schwab @ 2017-12-18 14:45 UTC (permalink / raw)
  To: H.J. Lu; +Cc: Florian Weimer, GNU C Library

On Dez 18 2017, "H.J. Lu" <hjl.tools@gmail.com> wrote:

> This patch adds bits/types/__cancel_jmp_buf_tag.h to define struct
> __cancel_jmp_buf_tag so that Linux/x86 can add saved_mask to
> cancel_jmp_buf.

Isn't that an ABI change?

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: [PATCH 1/2] Linux/x86: Update cancel_jmp_buf to match __jmp_buf_tag [BZ #22563]
  2017-12-18 14:45                                 ` Andreas Schwab
@ 2017-12-18 14:48                                   ` H.J. Lu
  2017-12-18 16:29                                     ` H.J. Lu
  2018-01-09 10:47                                     ` Florian Weimer
  0 siblings, 2 replies; 63+ messages in thread
From: H.J. Lu @ 2017-12-18 14:48 UTC (permalink / raw)
  To: Andreas Schwab; +Cc: Florian Weimer, GNU C Library

On Mon, Dec 18, 2017 at 6:44 AM, Andreas Schwab <schwab@suse.de> wrote:
> On Dez 18 2017, "H.J. Lu" <hjl.tools@gmail.com> wrote:
>
>> This patch adds bits/types/__cancel_jmp_buf_tag.h to define struct
>> __cancel_jmp_buf_tag so that Linux/x86 can add saved_mask to
>> cancel_jmp_buf.
>
> Isn't that an ABI change?
>

Yes, this change is exposed to application via <phread.h>.  The backward
binary compatibility is provided by

https://sourceware.org/ml/libc-alpha/2017-12/msg00208.html


-- 
H.J.

^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: [PATCH 1/2] Linux/x86: Update cancel_jmp_buf to match __jmp_buf_tag [BZ #22563]
  2017-12-18 14:48                                   ` H.J. Lu
@ 2017-12-18 16:29                                     ` H.J. Lu
  2018-01-09 10:47                                     ` Florian Weimer
  1 sibling, 0 replies; 63+ messages in thread
From: H.J. Lu @ 2017-12-18 16:29 UTC (permalink / raw)
  To: Andreas Schwab; +Cc: Florian Weimer, GNU C Library

On Mon, Dec 18, 2017 at 6:48 AM, H.J. Lu <hjl.tools@gmail.com> wrote:
> On Mon, Dec 18, 2017 at 6:44 AM, Andreas Schwab <schwab@suse.de> wrote:
>> On Dez 18 2017, "H.J. Lu" <hjl.tools@gmail.com> wrote:
>>
>>> This patch adds bits/types/__cancel_jmp_buf_tag.h to define struct
>>> __cancel_jmp_buf_tag so that Linux/x86 can add saved_mask to
>>> cancel_jmp_buf.
>>
>> Isn't that an ABI change?
>>
>
> Yes, this change is exposed to application via <phread.h>.  The backward
> binary compatibility is provided by
>
> https://sourceware.org/ml/libc-alpha/2017-12/msg00208.html
>

Here is the patch of shadow stack enabled setjmp/longjmp:

https://sourceware.org/ml/libc-alpha/2017-12/msg00559.html

which is backward binary compatible with existing binaries.

-- 
H.J.

^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: [PATCH 1/2] Linux/x86: Update cancel_jmp_buf to match __jmp_buf_tag [BZ #22563]
  2017-12-18 14:13                               ` H.J. Lu
  2017-12-18 14:45                                 ` Andreas Schwab
@ 2017-12-18 17:37                                 ` Joseph Myers
  2017-12-18 21:19                                   ` H.J. Lu
  1 sibling, 1 reply; 63+ messages in thread
From: Joseph Myers @ 2017-12-18 17:37 UTC (permalink / raw)
  To: H.J. Lu; +Cc: Florian Weimer, GNU C Library

I think any change applied to sysdeps/nptl/pthread.h should also be 
applied to sysdeps/unix/sysv/linux/hppa/pthread.h to avoid divergence 
between those header versions.

-- 
Joseph S. Myers
joseph@codesourcery.com

^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: [PATCH 1/2] Linux/x86: Update cancel_jmp_buf to match __jmp_buf_tag [BZ #22563]
  2017-12-18 17:37                                 ` [PATCH 1/2] Linux/x86: Update cancel_jmp_buf to match __jmp_buf_tag [BZ #22563] Joseph Myers
@ 2017-12-18 21:19                                   ` H.J. Lu
  0 siblings, 0 replies; 63+ messages in thread
From: H.J. Lu @ 2017-12-18 21:19 UTC (permalink / raw)
  To: Joseph Myers; +Cc: Florian Weimer, GNU C Library

[-- Attachment #1: Type: text/plain, Size: 468 bytes --]

On Mon, Dec 18, 2017 at 9:37 AM, Joseph Myers <joseph@codesourcery.com> wrote:
> I think any change applied to sysdeps/nptl/pthread.h should also be
> applied to sysdeps/unix/sysv/linux/hppa/pthread.h to avoid divergence
> between those header versions.
>

Here is the updated patch with sysdeps/unix/sysv/linux/hppa/pthread.h change.

Tested natively on i386, x86_64 and x32.  Tested hppa-linux-gnu with
build-many-glibcs.py.

I am checking it in tomorrow.

-- 
H.J.

[-- Attachment #2: 0001-Linux-x86-Update-cancel_jmp_buf-to-match-__jmp_buf_t.patch --]
[-- Type: text/x-patch, Size: 9954 bytes --]

From 2fc9116c385b43e69628dfcbfa7d9f7f8c32a03d Mon Sep 17 00:00:00 2001
From: "H.J. Lu" <hjl.tools@gmail.com>
Date: Wed, 6 Dec 2017 15:00:46 -0800
Subject: [PATCH] Linux/x86: Update cancel_jmp_buf to match __jmp_buf_tag [BZ
 #22563]

On x86, padding in struct __jmp_buf_tag is used for shadow stack pointer
to support shadow stack in Intel Control-flow Enforcemen Technology.
Since the cancel_jmp_buf array is passed to setjmp and longjmp by
casting it to pointer to struct __jmp_buf_tag, it should be as large
as struct __jmp_buf_tag.  Otherwise when shadow stack is enabled,
setjmp and longjmp will write and read beyond cancel_jmp_buf when saving
and restoring shadow stack pointer.

This patch adds bits/types/__cancel_jmp_buf_tag.h to define struct
__cancel_jmp_buf_tag so that Linux/x86 can add saved_mask to
cancel_jmp_buf.

Tested natively on i386, x86_64 and x32.  Tested hppa-linux-gnu with
build-many-glibcs.py.

	[BZ #22563]
	* bits/types/__cancel_jmp_buf_tag.h: New file.
	* sysdeps/unix/sysv/linux/x86/bits/types/__cancel_jmp_buf_tag.h
	* sysdeps/unix/sysv/linux/x86/pthreaddef.h: Likewise.
	* sysdeps/unix/sysv/linux/x86/nptl/pthreadP.h: Likewise.
	* nptl/Makefile (headers): Add
	bits/types/__cancel_jmp_buf_tag.h.
	* nptl/descr.h [NEED_SAVED_MASK_IN_CANCEL_JMP_BUF]
	(pthread_unwind_buf): Add saved_mask to cancel_jmp_buf.
	* sysdeps/nptl/pthread.h: Include
	<bits/types/__cancel_jmp_buf_tag.h>.
	(__pthread_unwind_buf_t): Use struct __cancel_jmp_buf_tag with
	__cancel_jmp_buf.
	* sysdeps/unix/sysv/linux/hppa/pthread.h: Likewise.
---
 bits/types/__cancel_jmp_buf_tag.h                  | 28 +++++++++++++++++
 nptl/Makefile                                      |  3 +-
 nptl/descr.h                                       |  3 ++
 sysdeps/nptl/pthread.h                             |  7 ++---
 sysdeps/unix/sysv/linux/hppa/pthread.h             |  7 ++---
 .../linux/x86/bits/types/__cancel_jmp_buf_tag.h    | 31 +++++++++++++++++++
 sysdeps/unix/sysv/linux/x86/nptl/pthreadP.h        | 36 ++++++++++++++++++++++
 sysdeps/unix/sysv/linux/x86/pthreaddef.h           | 22 +++++++++++++
 8 files changed, 126 insertions(+), 11 deletions(-)
 create mode 100644 bits/types/__cancel_jmp_buf_tag.h
 create mode 100644 sysdeps/unix/sysv/linux/x86/bits/types/__cancel_jmp_buf_tag.h
 create mode 100644 sysdeps/unix/sysv/linux/x86/nptl/pthreadP.h
 create mode 100644 sysdeps/unix/sysv/linux/x86/pthreaddef.h

diff --git a/bits/types/__cancel_jmp_buf_tag.h b/bits/types/__cancel_jmp_buf_tag.h
new file mode 100644
index 0000000000..c843f44239
--- /dev/null
+++ b/bits/types/__cancel_jmp_buf_tag.h
@@ -0,0 +1,28 @@
+/* Define struct __cancel_jmp_buf_tag.
+   Copyright (C) 2017 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/>.  */
+
+#ifndef ____cancel_jmp_buf_tag_defined
+#define ____cancel_jmp_buf_tag_defined 1
+
+struct __cancel_jmp_buf_tag
+  {
+    __jmp_buf __cancel_jmp_buf;
+    int __mask_was_saved;
+  };
+
+#endif
diff --git a/nptl/Makefile b/nptl/Makefile
index 570a42301c..60d036a1ea 100644
--- a/nptl/Makefile
+++ b/nptl/Makefile
@@ -22,7 +22,8 @@ subdir	:= nptl
 
 include ../Makeconfig
 
-headers := pthread.h semaphore.h bits/semaphore.h
+headers := pthread.h semaphore.h bits/semaphore.h \
+	   bits/types/__cancel_jmp_buf_tag.h
 
 extra-libs := libpthread
 extra-libs-others := $(extra-libs)
diff --git a/nptl/descr.h b/nptl/descr.h
index c83b17b674..fdeb397eab 100644
--- a/nptl/descr.h
+++ b/nptl/descr.h
@@ -65,6 +65,9 @@ struct pthread_unwind_buf
   {
     __jmp_buf jmp_buf;
     int mask_was_saved;
+#ifdef NEED_SAVED_MASK_IN_CANCEL_JMP_BUF
+    __sigset_t saved_mask;
+#endif
   } cancel_jmp_buf[1];
 
   union
diff --git a/sysdeps/nptl/pthread.h b/sysdeps/nptl/pthread.h
index 2b2b386ab3..787ac6e4cd 100644
--- a/sysdeps/nptl/pthread.h
+++ b/sysdeps/nptl/pthread.h
@@ -27,6 +27,7 @@
 #include <bits/setjmp.h>
 #include <bits/wordsize.h>
 #include <bits/types/struct_timespec.h>
+#include <bits/types/__cancel_jmp_buf_tag.h>
 
 
 /* Detach state.  */
@@ -523,11 +524,7 @@ extern void pthread_testcancel (void);
 
 typedef struct
 {
-  struct
-  {
-    __jmp_buf __cancel_jmp_buf;
-    int __mask_was_saved;
-  } __cancel_jmp_buf[1];
+  struct __cancel_jmp_buf_tag __cancel_jmp_buf[1];
   void *__pad[4];
 } __pthread_unwind_buf_t __attribute__ ((__aligned__));
 
diff --git a/sysdeps/unix/sysv/linux/hppa/pthread.h b/sysdeps/unix/sysv/linux/hppa/pthread.h
index d1973741cd..3d69ddcd00 100644
--- a/sysdeps/unix/sysv/linux/hppa/pthread.h
+++ b/sysdeps/unix/sysv/linux/hppa/pthread.h
@@ -27,6 +27,7 @@
 #include <bits/setjmp.h>
 #include <bits/wordsize.h>
 #include <bits/types/struct_timespec.h>
+#include <bits/types/__cancel_jmp_buf_tag.h>
 
 
 /* Detach state.  */
@@ -499,11 +500,7 @@ extern void pthread_testcancel (void);
 
 typedef struct
 {
-  struct
-  {
-    __jmp_buf __cancel_jmp_buf;
-    int __mask_was_saved;
-  } __cancel_jmp_buf[1];
+  struct __cancel_jmp_buf_tag __cancel_jmp_buf[1];
   void *__pad[4];
 } __pthread_unwind_buf_t __attribute__ ((__aligned__));
 
diff --git a/sysdeps/unix/sysv/linux/x86/bits/types/__cancel_jmp_buf_tag.h b/sysdeps/unix/sysv/linux/x86/bits/types/__cancel_jmp_buf_tag.h
new file mode 100644
index 0000000000..830a6ec90c
--- /dev/null
+++ b/sysdeps/unix/sysv/linux/x86/bits/types/__cancel_jmp_buf_tag.h
@@ -0,0 +1,31 @@
+/* Define struct __cancel_jmp_buf_tag.
+   Copyright (C) 2017 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/>.  */
+
+#ifndef ____cancel_jmp_buf_tag_defined
+#define ____cancel_jmp_buf_tag_defined 1
+
+#include <bits/types/__sigset_t.h>
+
+struct __cancel_jmp_buf_tag
+  {
+    __jmp_buf __cancel_jmp_buf;
+    int __mask_was_saved;
+    __sigset_t __saved_mask;
+  };
+
+#endif
diff --git a/sysdeps/unix/sysv/linux/x86/nptl/pthreadP.h b/sysdeps/unix/sysv/linux/x86/nptl/pthreadP.h
new file mode 100644
index 0000000000..8c36ba3a5d
--- /dev/null
+++ b/sysdeps/unix/sysv/linux/x86/nptl/pthreadP.h
@@ -0,0 +1,36 @@
+/* Internal pthread header.  Linux/x86 version.
+   Copyright (C) 2017 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/>.  */
+
+#include_next <nptl/pthreadP.h>
+
+#ifndef _PTHREADP_H_X86
+#define _PTHREADP_H_X86 1
+
+extern struct pthread_unwind_buf ____pthread_unwind_buf_private;
+
+_Static_assert (sizeof (____pthread_unwind_buf_private.cancel_jmp_buf)
+		>= sizeof (struct __jmp_buf_tag),
+		"size of cancel_jmp_buf < sizeof __jmp_buf_tag");
+
+extern __pthread_unwind_buf_t ____pthread_unwind_buf;
+
+_Static_assert (sizeof (____pthread_unwind_buf.__cancel_jmp_buf)
+		>= sizeof (struct __jmp_buf_tag),
+		"size of __cancel_jmp_buf < sizeof __jmp_buf_tag");
+
+#endif
diff --git a/sysdeps/unix/sysv/linux/x86/pthreaddef.h b/sysdeps/unix/sysv/linux/x86/pthreaddef.h
new file mode 100644
index 0000000000..89d19d60a1
--- /dev/null
+++ b/sysdeps/unix/sysv/linux/x86/pthreaddef.h
@@ -0,0 +1,22 @@
+/* Pthread macros.  Linux/x86 version.
+   Copyright (C) 2017 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/>.  */
+
+#include_next <pthreaddef.h>
+
+/* Need saved_mask in cancel_jmp_buf.  */
+#define NEED_SAVED_MASK_IN_CANCEL_JMP_BUF 1
-- 
2.14.3


^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: [PATCH 1/2] Linux/x86: Update cancel_jmp_buf to match __jmp_buf_tag [BZ #22563]
  2017-12-18 14:48                                   ` H.J. Lu
  2017-12-18 16:29                                     ` H.J. Lu
@ 2018-01-09 10:47                                     ` Florian Weimer
  2018-01-09 12:17                                       ` H.J. Lu
  2018-01-21 16:16                                       ` Aurelien Jarno
  1 sibling, 2 replies; 63+ messages in thread
From: Florian Weimer @ 2018-01-09 10:47 UTC (permalink / raw)
  To: H.J. Lu, Andreas Schwab; +Cc: GNU C Library

On 12/18/2017 03:48 PM, H.J. Lu wrote:
> On Mon, Dec 18, 2017 at 6:44 AM, Andreas Schwab <schwab@suse.de> wrote:
>> On Dez 18 2017, "H.J. Lu" <hjl.tools@gmail.com> wrote:
>>
>>> This patch adds bits/types/__cancel_jmp_buf_tag.h to define struct
>>> __cancel_jmp_buf_tag so that Linux/x86 can add saved_mask to
>>> cancel_jmp_buf.
>>
>> Isn't that an ABI change?
>>
> 
> Yes, this change is exposed to application via <phread.h>.  The backward
> binary compatibility is provided by
> 
> https://sourceware.org/ml/libc-alpha/2017-12/msg00208.html

This doesn't seem to work:

<https://sourceware.org/ml/libc-alpha/2018-01/msg00178.html>

I have no idea what is going on, but if we can't find the root cause, I 
think we should revert all the setjmp changes.

Thanks,
Florian

^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: [PATCH 1/2] Linux/x86: Update cancel_jmp_buf to match __jmp_buf_tag [BZ #22563]
  2018-01-09 10:47                                     ` Florian Weimer
@ 2018-01-09 12:17                                       ` H.J. Lu
  2018-01-09 16:20                                         ` Senkevich, Andrew
  2018-01-21 16:16                                       ` Aurelien Jarno
  1 sibling, 1 reply; 63+ messages in thread
From: H.J. Lu @ 2018-01-09 12:17 UTC (permalink / raw)
  To: Florian Weimer, Tsimbalist, Igor V, Senkevich, Andrew
  Cc: Andreas Schwab, GNU C Library

On Tue, Jan 9, 2018 at 2:47 AM, Florian Weimer <fweimer@redhat.com> wrote:
> On 12/18/2017 03:48 PM, H.J. Lu wrote:
>>
>> On Mon, Dec 18, 2017 at 6:44 AM, Andreas Schwab <schwab@suse.de> wrote:
>>>
>>> On Dez 18 2017, "H.J. Lu" <hjl.tools@gmail.com> wrote:
>>>
>>>> This patch adds bits/types/__cancel_jmp_buf_tag.h to define struct
>>>> __cancel_jmp_buf_tag so that Linux/x86 can add saved_mask to
>>>> cancel_jmp_buf.
>>>
>>>
>>> Isn't that an ABI change?
>>>
>>
>> Yes, this change is exposed to application via <phread.h>.  The backward
>> binary compatibility is provided by
>>
>> https://sourceware.org/ml/libc-alpha/2017-12/msg00208.html
>
>
> This doesn't seem to work:
>
> <https://sourceware.org/ml/libc-alpha/2018-01/msg00178.html>
>
> I have no idea what is going on, but if we can't find the root cause, I
> think we should revert all the setjmp changes.

Hi Andrew, Igor,

Please investigate to find out what happened.

Thanks.

-- 
H.J.

^ permalink raw reply	[flat|nested] 63+ messages in thread

* RE: [PATCH 1/2] Linux/x86: Update cancel_jmp_buf to match __jmp_buf_tag [BZ #22563]
  2018-01-09 12:17                                       ` H.J. Lu
@ 2018-01-09 16:20                                         ` Senkevich, Andrew
  0 siblings, 0 replies; 63+ messages in thread
From: Senkevich, Andrew @ 2018-01-09 16:20 UTC (permalink / raw)
  To: H.J. Lu, Florian Weimer, Tsimbalist, Igor V; +Cc: Andreas Schwab, GNU C Library

> -----Original Message-----
> From: H.J. Lu [mailto:hjl.tools@gmail.com]
> Sent: Tuesday, January 9, 2018 13:18
> To: Florian Weimer <fweimer@redhat.com>; Tsimbalist, Igor V
> <igor.v.tsimbalist@intel.com>; Senkevich, Andrew
> <andrew.senkevich@intel.com>
> Cc: Andreas Schwab <schwab@suse.de>; GNU C Library <libc-
> alpha@sourceware.org>
> Subject: Re: [PATCH 1/2] Linux/x86: Update cancel_jmp_buf to match
> __jmp_buf_tag [BZ #22563]
> 
> On Tue, Jan 9, 2018 at 2:47 AM, Florian Weimer <fweimer@redhat.com>
> wrote:
> > On 12/18/2017 03:48 PM, H.J. Lu wrote:
> >>
> >> On Mon, Dec 18, 2017 at 6:44 AM, Andreas Schwab <schwab@suse.de>
> wrote:
> >>>
> >>> On Dez 18 2017, "H.J. Lu" <hjl.tools@gmail.com> wrote:
> >>>
> >>>> This patch adds bits/types/__cancel_jmp_buf_tag.h to define struct
> >>>> __cancel_jmp_buf_tag so that Linux/x86 can add saved_mask to
> >>>> cancel_jmp_buf.
> >>>
> >>>
> >>> Isn't that an ABI change?
> >>>
> >>
> >> Yes, this change is exposed to application via <phread.h>.  The
> >> backward binary compatibility is provided by
> >>
> >> https://sourceware.org/ml/libc-alpha/2017-12/msg00208.html
> >
> >
> > This doesn't seem to work:
> >
> > <https://sourceware.org/ml/libc-alpha/2018-01/msg00178.html>
> >
> > I have no idea what is going on, but if we can't find the root cause,
> > I think we should revert all the setjmp changes.
> 
> Hi Andrew, Igor,
> 
> Please investigate to find out what happened.
> 
> Thanks.

We have connected with Tom Englund who reported issue and we will work on this issue.


--
Andrew

^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: [PATCH 1/2] Linux/x86: Update cancel_jmp_buf to match __jmp_buf_tag [BZ #22563]
  2018-01-09 10:47                                     ` Florian Weimer
  2018-01-09 12:17                                       ` H.J. Lu
@ 2018-01-21 16:16                                       ` Aurelien Jarno
  2018-01-21 16:27                                         ` H.J. Lu
  1 sibling, 1 reply; 63+ messages in thread
From: Aurelien Jarno @ 2018-01-21 16:16 UTC (permalink / raw)
  To: Florian Weimer; +Cc: H.J. Lu, Andreas Schwab, GNU C Library

On 2018-01-09 11:47, Florian Weimer wrote:
> On 12/18/2017 03:48 PM, H.J. Lu wrote:
> > On Mon, Dec 18, 2017 at 6:44 AM, Andreas Schwab <schwab@suse.de> wrote:
> > > On Dez 18 2017, "H.J. Lu" <hjl.tools@gmail.com> wrote:
> > > 
> > > > This patch adds bits/types/__cancel_jmp_buf_tag.h to define struct
> > > > __cancel_jmp_buf_tag so that Linux/x86 can add saved_mask to
> > > > cancel_jmp_buf.
> > > 
> > > Isn't that an ABI change?
> > > 
> > 
> > Yes, this change is exposed to application via <phread.h>.  The backward
> > binary compatibility is provided by
> > 
> > https://sourceware.org/ml/libc-alpha/2017-12/msg00208.html
> 
> This doesn't seem to work:
> 
> <https://sourceware.org/ml/libc-alpha/2018-01/msg00178.html>
> 
> I have no idea what is going on, but if we can't find the root cause, I
> think we should revert all the setjmp changes.

Commit f81ddabffd also breaks software like vlc or amarok, they crash
with a segmentation fault during startup. Reverting the commit
f81ddabffd fixes the issue.

See debian bugs #887078 and #887886.

-- 
Aurelien Jarno                          GPG: 4096R/1DDD8C9B
aurelien@aurel32.net                 http://www.aurel32.net

^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: [PATCH 1/2] Linux/x86: Update cancel_jmp_buf to match __jmp_buf_tag [BZ #22563]
  2018-01-21 16:16                                       ` Aurelien Jarno
@ 2018-01-21 16:27                                         ` H.J. Lu
  2018-01-21 16:50                                           ` Carlos O'Donell
  2018-01-22 14:44                                           ` Senkevich, Andrew
  0 siblings, 2 replies; 63+ messages in thread
From: H.J. Lu @ 2018-01-21 16:27 UTC (permalink / raw)
  To: Florian Weimer, Andreas Schwab, GNU C Library, Senkevich, Andrew

On Sun, Jan 21, 2018 at 8:15 AM, Aurelien Jarno <aurelien@aurel32.net> wrote:
> On 2018-01-09 11:47, Florian Weimer wrote:
>> On 12/18/2017 03:48 PM, H.J. Lu wrote:
>> > On Mon, Dec 18, 2017 at 6:44 AM, Andreas Schwab <schwab@suse.de> wrote:
>> > > On Dez 18 2017, "H.J. Lu" <hjl.tools@gmail.com> wrote:
>> > >
>> > > > This patch adds bits/types/__cancel_jmp_buf_tag.h to define struct
>> > > > __cancel_jmp_buf_tag so that Linux/x86 can add saved_mask to
>> > > > cancel_jmp_buf.
>> > >
>> > > Isn't that an ABI change?
>> > >
>> >
>> > Yes, this change is exposed to application via <phread.h>.  The backward
>> > binary compatibility is provided by
>> >
>> > https://sourceware.org/ml/libc-alpha/2017-12/msg00208.html
>>
>> This doesn't seem to work:
>>
>> <https://sourceware.org/ml/libc-alpha/2018-01/msg00178.html>
>>
>> I have no idea what is going on, but if we can't find the root cause, I
>> think we should revert all the setjmp changes.
>
> Commit f81ddabffd also breaks software like vlc or amarok, they crash
> with a segmentation fault during startup. Reverting the commit
> f81ddabffd fixes the issue.
>
> See debian bugs #887078 and #887886.
>

Hi Andrew,

This may be easier to track.  Please investigate.

-- 
H.J.

^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: [PATCH 1/2] Linux/x86: Update cancel_jmp_buf to match __jmp_buf_tag [BZ #22563]
  2018-01-21 16:27                                         ` H.J. Lu
@ 2018-01-21 16:50                                           ` Carlos O'Donell
  2018-01-22 14:44                                           ` Senkevich, Andrew
  1 sibling, 0 replies; 63+ messages in thread
From: Carlos O'Donell @ 2018-01-21 16:50 UTC (permalink / raw)
  To: H.J. Lu, Florian Weimer, Andreas Schwab, GNU C Library,
	Senkevich, Andrew

On 01/21/2018 08:27 AM, H.J. Lu wrote:
> On Sun, Jan 21, 2018 at 8:15 AM, Aurelien Jarno <aurelien@aurel32.net> wrote:
>> On 2018-01-09 11:47, Florian Weimer wrote:
>>> On 12/18/2017 03:48 PM, H.J. Lu wrote:
>>>> On Mon, Dec 18, 2017 at 6:44 AM, Andreas Schwab <schwab@suse.de> wrote:
>>>>> On Dez 18 2017, "H.J. Lu" <hjl.tools@gmail.com> wrote:
>>>>>
>>>>>> This patch adds bits/types/__cancel_jmp_buf_tag.h to define struct
>>>>>> __cancel_jmp_buf_tag so that Linux/x86 can add saved_mask to
>>>>>> cancel_jmp_buf.
>>>>>
>>>>> Isn't that an ABI change?
>>>>>
>>>>
>>>> Yes, this change is exposed to application via <phread.h>.  The backward
>>>> binary compatibility is provided by
>>>>
>>>> https://sourceware.org/ml/libc-alpha/2017-12/msg00208.html
>>>
>>> This doesn't seem to work:
>>>
>>> <https://sourceware.org/ml/libc-alpha/2018-01/msg00178.html>
>>>
>>> I have no idea what is going on, but if we can't find the root cause, I
>>> think we should revert all the setjmp changes.
>>
>> Commit f81ddabffd also breaks software like vlc or amarok, they crash
>> with a segmentation fault during startup. Reverting the commit
>> f81ddabffd fixes the issue.
>>
>> See debian bugs #887078 and #887886.
>>
> 
> Hi Andrew,
> 
> This may be easier to track.  Please investigate.
 
This is now the last remaining release blocker IMO.

I'm going to start investigating this on Monday.

-- 
Cheers,
Carlos.

^ permalink raw reply	[flat|nested] 63+ messages in thread

* RE: [PATCH 1/2] Linux/x86: Update cancel_jmp_buf to match __jmp_buf_tag [BZ #22563]
  2018-01-21 16:27                                         ` H.J. Lu
  2018-01-21 16:50                                           ` Carlos O'Donell
@ 2018-01-22 14:44                                           ` Senkevich, Andrew
  2018-01-23 19:35                                             ` Carlos O'Donell
  1 sibling, 1 reply; 63+ messages in thread
From: Senkevich, Andrew @ 2018-01-22 14:44 UTC (permalink / raw)
  To: H.J. Lu, Florian Weimer, Andreas Schwab; +Cc: GNU C Library

> -----Original Message-----
> From: H.J. Lu [mailto:hjl.tools@gmail.com]
> Sent: Sunday, January 21, 2018 17:27
> To: Florian Weimer <fweimer@redhat.com>; Andreas Schwab
> <schwab@suse.de>; GNU C Library <libc-alpha@sourceware.org>;
> Senkevich, Andrew <andrew.senkevich@intel.com>
> Subject: Re: [PATCH 1/2] Linux/x86: Update cancel_jmp_buf to match
> __jmp_buf_tag [BZ #22563]
> 
> On Sun, Jan 21, 2018 at 8:15 AM, Aurelien Jarno <aurelien@aurel32.net>
> wrote:
> > On 2018-01-09 11:47, Florian Weimer wrote:
> >> On 12/18/2017 03:48 PM, H.J. Lu wrote:
> >> > On Mon, Dec 18, 2017 at 6:44 AM, Andreas Schwab <schwab@suse.de>
> wrote:
> >> > > On Dez 18 2017, "H.J. Lu" <hjl.tools@gmail.com> wrote:
> >> > >
> >> > > > This patch adds bits/types/__cancel_jmp_buf_tag.h to define
> >> > > > struct __cancel_jmp_buf_tag so that Linux/x86 can add
> >> > > > saved_mask to cancel_jmp_buf.
> >> > >
> >> > > Isn't that an ABI change?
> >> > >
> >> >
> >> > Yes, this change is exposed to application via <phread.h>.  The
> >> > backward binary compatibility is provided by
> >> >
> >> > https://sourceware.org/ml/libc-alpha/2017-12/msg00208.html
> >>
> >> This doesn't seem to work:
> >>
> >> <https://sourceware.org/ml/libc-alpha/2018-01/msg00178.html>
> >>
> >> I have no idea what is going on, but if we can't find the root cause,
> >> I think we should revert all the setjmp changes.
> >
> > Commit f81ddabffd also breaks software like vlc or amarok, they crash
> > with a segmentation fault during startup. Reverting the commit
> > f81ddabffd fixes the issue.
> >
> > See debian bugs #887078 and #887886.
> >
> 
> Hi Andrew,
> 
> This may be easier to track.  Please investigate.

Looks like that.
I will have ability to investigate it during tomorrow.


--
Andrew

^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: [PATCH 1/2] Linux/x86: Update cancel_jmp_buf to match __jmp_buf_tag [BZ #22563]
  2018-01-22 14:44                                           ` Senkevich, Andrew
@ 2018-01-23 19:35                                             ` Carlos O'Donell
  2018-01-23 21:13                                               ` Senkevich, Andrew
  0 siblings, 1 reply; 63+ messages in thread
From: Carlos O'Donell @ 2018-01-23 19:35 UTC (permalink / raw)
  To: Senkevich, Andrew, H.J. Lu, Florian Weimer, Andreas Schwab; +Cc: GNU C Library

On 01/22/2018 06:44 AM, Senkevich, Andrew wrote:
> Looks like that.
> I will have ability to investigate it during tomorrow.

Any idea what's going wrong?

-- 
Cheers,
Carlos.

^ permalink raw reply	[flat|nested] 63+ messages in thread

* RE: [PATCH 1/2] Linux/x86: Update cancel_jmp_buf to match __jmp_buf_tag [BZ #22563]
  2018-01-23 19:35                                             ` Carlos O'Donell
@ 2018-01-23 21:13                                               ` Senkevich, Andrew
  2018-01-24 18:08                                                 ` H.J. Lu
  0 siblings, 1 reply; 63+ messages in thread
From: Senkevich, Andrew @ 2018-01-23 21:13 UTC (permalink / raw)
  To: Carlos O'Donell, H.J. Lu, Florian Weimer, Andreas Schwab
  Cc: GNU C Library

> -----Original Message-----
> From: Carlos O'Donell [mailto:carlos@redhat.com]
> Sent: Tuesday, January 23, 2018 20:35
> To: Senkevich, Andrew <andrew.senkevich@intel.com>; H.J. Lu
> <hjl.tools@gmail.com>; Florian Weimer <fweimer@redhat.com>; Andreas
> Schwab <schwab@suse.de>
> Cc: GNU C Library <libc-alpha@sourceware.org>
> Subject: Re: [PATCH 1/2] Linux/x86: Update cancel_jmp_buf to match
> __jmp_buf_tag [BZ #22563]
> 
> On 01/22/2018 06:44 AM, Senkevich, Andrew wrote:
> > Looks like that.
> > I will have ability to investigate it during tomorrow.
> 
> Any idea what's going wrong?

Currently not clear why but I see return from var_AddCallback () (from /usr/lib/x86_64-linux-gnu/libvlccore.so.9) to wrong address.
And setjmp/longjmp doesn't break. Will continue tomorrow.

--
Andrew

^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: [PATCH 1/2] Linux/x86: Update cancel_jmp_buf to match __jmp_buf_tag [BZ #22563]
  2018-01-23 21:13                                               ` Senkevich, Andrew
@ 2018-01-24 18:08                                                 ` H.J. Lu
  2018-01-24 18:23                                                   ` Florian Weimer
  0 siblings, 1 reply; 63+ messages in thread
From: H.J. Lu @ 2018-01-24 18:08 UTC (permalink / raw)
  To: Senkevich, Andrew
  Cc: Carlos O'Donell, Florian Weimer, Andreas Schwab, GNU C Library

On Tue, Jan 23, 2018 at 1:13 PM, Senkevich, Andrew
<andrew.senkevich@intel.com> wrote:
>> -----Original Message-----
>> From: Carlos O'Donell [mailto:carlos@redhat.com]
>> Sent: Tuesday, January 23, 2018 20:35
>> To: Senkevich, Andrew <andrew.senkevich@intel.com>; H.J. Lu
>> <hjl.tools@gmail.com>; Florian Weimer <fweimer@redhat.com>; Andreas
>> Schwab <schwab@suse.de>
>> Cc: GNU C Library <libc-alpha@sourceware.org>
>> Subject: Re: [PATCH 1/2] Linux/x86: Update cancel_jmp_buf to match
>> __jmp_buf_tag [BZ #22563]
>>
>> On 01/22/2018 06:44 AM, Senkevich, Andrew wrote:
>> > Looks like that.
>> > I will have ability to investigate it during tomorrow.
>>
>> Any idea what's going wrong?
>
> Currently not clear why but I see return from var_AddCallback () (from /usr/lib/x86_64-linux-gnu/libvlccore.so.9) to wrong address.
> And setjmp/longjmp doesn't break. Will continue tomorrow.
>

We opened a bug:

https://sourceware.org/bugzilla/show_bug.cgi?id=22743

Any help to track down the root cause is appreciated.

-- 
H.J.

^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: [PATCH 1/2] Linux/x86: Update cancel_jmp_buf to match __jmp_buf_tag [BZ #22563]
  2018-01-24 18:08                                                 ` H.J. Lu
@ 2018-01-24 18:23                                                   ` Florian Weimer
  2018-01-25  0:32                                                     ` Carlos O'Donell
  0 siblings, 1 reply; 63+ messages in thread
From: Florian Weimer @ 2018-01-24 18:23 UTC (permalink / raw)
  To: H.J. Lu, Senkevich, Andrew
  Cc: Carlos O'Donell, Andreas Schwab, GNU C Library

On 01/24/2018 07:08 PM, H.J. Lu wrote:
> On Tue, Jan 23, 2018 at 1:13 PM, Senkevich, Andrew
> <andrew.senkevich@intel.com> wrote:
>>> -----Original Message-----
>>> From: Carlos O'Donell [mailto:carlos@redhat.com]
>>> Sent: Tuesday, January 23, 2018 20:35
>>> To: Senkevich, Andrew <andrew.senkevich@intel.com>; H.J. Lu
>>> <hjl.tools@gmail.com>; Florian Weimer <fweimer@redhat.com>; Andreas
>>> Schwab <schwab@suse.de>
>>> Cc: GNU C Library <libc-alpha@sourceware.org>
>>> Subject: Re: [PATCH 1/2] Linux/x86: Update cancel_jmp_buf to match
>>> __jmp_buf_tag [BZ #22563]
>>>
>>> On 01/22/2018 06:44 AM, Senkevich, Andrew wrote:
>>>> Looks like that.
>>>> I will have ability to investigate it during tomorrow.
>>>
>>> Any idea what's going wrong?
>>
>> Currently not clear why but I see return from var_AddCallback () (from /usr/lib/x86_64-linux-gnu/libvlccore.so.9) to wrong address.
>> And setjmp/longjmp doesn't break. Will continue tomorrow.
>>
> 
> We opened a bug:
> 
> https://sourceware.org/bugzilla/show_bug.cgi?id=22743
> 
> Any help to track down the root cause is appreciated.

Doesn't the bug report clearly show the root cause?  The offset of 
priv.data.cleanup changed, and old binaries have an insufficiently large 
stack allocation for the new offset.

(Congratulations for tracking it down, by the way.  I know that such 
bugs are hard.)

You need to add a symbol version for pthread_register_cancel.  It's too 
late for that now, so I recommend reverting the faulty commit.

Thanks,
Florian

^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: [PATCH 1/2] Linux/x86: Update cancel_jmp_buf to match __jmp_buf_tag [BZ #22563]
  2018-01-24 18:23                                                   ` Florian Weimer
@ 2018-01-25  0:32                                                     ` Carlos O'Donell
  2018-01-25  0:56                                                       ` Joseph Myers
  2018-01-25  1:09                                                       ` H.J. Lu
  0 siblings, 2 replies; 63+ messages in thread
From: Carlos O'Donell @ 2018-01-25  0:32 UTC (permalink / raw)
  To: Florian Weimer, H.J. Lu, Senkevich, Andrew; +Cc: Andreas Schwab, GNU C Library

On 01/24/2018 10:23 AM, Florian Weimer wrote:
> On 01/24/2018 07:08 PM, H.J. Lu wrote:
>> We opened a bug:
>> 
>> https://sourceware.org/bugzilla/show_bug.cgi?id=22743
>> 
>> Any help to track down the root cause is appreciated.
> 
> Doesn't the bug report clearly show the root cause?  The offset of
> priv.data.cleanup changed, and old binaries have an insufficiently
> large stack allocation for the new offset.
> 
> (Congratulations for tracking it down, by the way.  I know that such
> bugs are hard.)
> 
> You need to add a symbol version for pthread_register_cancel.  It's
> too late for that now, so I recommend reverting the faulty commit.

I have finished analyzing this and debugging the root cause myself,
and I agree with Florian, we need to revert:

commit f81ddabffd76ac9dd600b02adbf3e1dac4bb10ec
commit cba595c350e52194e10c0006732e1991e3d0803b

At a minimum. I am testing with them reverted locally.

To be honest I'm surprised that this passed review and was checked
in, because the __pthread_unwind_buf_t has only at most 4-bytes of
space left before it is an ABI change. In the future please ping
me if you have any doubts and I'll review.

The addition of __sigset_t saved_mask moves pthread_unwind_buf's
priv.data.cleanup forward by 124-bytes. The on-stack allocation of
the pthread_cleanup_push's __pthread_unwind_buf_t is not that big
and so __pthread_register_cancel writes to other structures which
are allocated on the stack.

You cannot expand struct pthread_unwind_buf because the on-stack
allocated __pthread_unwind_buf_t is not large enough in existing
applications.

You *might* have used feature_1 to change between two different
layouts of struct pthread_unwind_buf, but that will have to wait
for 2.28. As Florian suggests though it is cleaner to version
__pthread_register_cancel for x86 and the older version expects
the smaller non-CET-enabled structure.

-- 
Cheers,
Carlos.

^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: [PATCH 1/2] Linux/x86: Update cancel_jmp_buf to match __jmp_buf_tag [BZ #22563]
  2018-01-25  0:32                                                     ` Carlos O'Donell
@ 2018-01-25  0:56                                                       ` Joseph Myers
  2018-01-25  1:09                                                       ` H.J. Lu
  1 sibling, 0 replies; 63+ messages in thread
From: Joseph Myers @ 2018-01-25  0:56 UTC (permalink / raw)
  To: Carlos O'Donell
  Cc: Florian Weimer, H.J. Lu, Senkevich, Andrew, Andreas Schwab,
	GNU C Library

On Wed, 24 Jan 2018, Carlos O'Donell wrote:

> I have finished analyzing this and debugging the root cause myself,
> and I agree with Florian, we need to revert:
> 
> commit f81ddabffd76ac9dd600b02adbf3e1dac4bb10ec
> commit cba595c350e52194e10c0006732e1991e3d0803b
> 
> At a minimum. I am testing with them reverted locally.
> 
> To be honest I'm surprised that this passed review and was checked
> in, because the __pthread_unwind_buf_t has only at most 4-bytes of

It didn't pass review.  It was checked in with no evidence of consensus 
(and even with ABI concerns raised in the original discussion).

-- 
Joseph S. Myers
joseph@codesourcery.com

^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: [PATCH 1/2] Linux/x86: Update cancel_jmp_buf to match __jmp_buf_tag [BZ #22563]
  2018-01-25  0:32                                                     ` Carlos O'Donell
  2018-01-25  0:56                                                       ` Joseph Myers
@ 2018-01-25  1:09                                                       ` H.J. Lu
  2018-01-25  1:44                                                         ` Carlos O'Donell
  2018-01-25  1:48                                                         ` Dmitry V. Levin
  1 sibling, 2 replies; 63+ messages in thread
From: H.J. Lu @ 2018-01-25  1:09 UTC (permalink / raw)
  To: Carlos O'Donell
  Cc: Florian Weimer, Senkevich, Andrew, Andreas Schwab, GNU C Library

On Wed, Jan 24, 2018 at 4:32 PM, Carlos O'Donell <carlos@redhat.com> wrote:
> On 01/24/2018 10:23 AM, Florian Weimer wrote:
>> On 01/24/2018 07:08 PM, H.J. Lu wrote:
>>> We opened a bug:
>>>
>>> https://sourceware.org/bugzilla/show_bug.cgi?id=22743
>>>
>>> Any help to track down the root cause is appreciated.
>>
>> Doesn't the bug report clearly show the root cause?  The offset of
>> priv.data.cleanup changed, and old binaries have an insufficiently
>> large stack allocation for the new offset.
>>
>> (Congratulations for tracking it down, by the way.  I know that such
>> bugs are hard.)
>>
>> You need to add a symbol version for pthread_register_cancel.  It's
>> too late for that now, so I recommend reverting the faulty commit.
>
> I have finished analyzing this and debugging the root cause myself,
> and I agree with Florian, we need to revert:
>
> commit f81ddabffd76ac9dd600b02adbf3e1dac4bb10ec
> commit cba595c350e52194e10c0006732e1991e3d0803b
>
> At a minimum. I am testing with them reverted locally.
>
> To be honest I'm surprised that this passed review and was checked
> in, because the __pthread_unwind_buf_t has only at most 4-bytes of
> space left before it is an ABI change. In the future please ping
> me if you have any doubts and I'll review.
>
> The addition of __sigset_t saved_mask moves pthread_unwind_buf's
> priv.data.cleanup forward by 124-bytes. The on-stack allocation of
> the pthread_cleanup_push's __pthread_unwind_buf_t is not that big
> and so __pthread_register_cancel writes to other structures which
> are allocated on the stack.
>
> You cannot expand struct pthread_unwind_buf because the on-stack
> allocated __pthread_unwind_buf_t is not large enough in existing
> applications.
>
> You *might* have used feature_1 to change between two different
> layouts of struct pthread_unwind_buf, but that will have to wait
> for 2.28. As Florian suggests though it is cleaner to version
> __pthread_register_cancel for x86 and the older version expects
> the smaller non-CET-enabled structure.
>

I will try to fix it by next Monday.


-- 
H.J.

^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: [PATCH 1/2] Linux/x86: Update cancel_jmp_buf to match __jmp_buf_tag [BZ #22563]
  2018-01-25  1:09                                                       ` H.J. Lu
@ 2018-01-25  1:44                                                         ` Carlos O'Donell
  2018-01-25  1:48                                                         ` Dmitry V. Levin
  1 sibling, 0 replies; 63+ messages in thread
From: Carlos O'Donell @ 2018-01-25  1:44 UTC (permalink / raw)
  To: H.J. Lu; +Cc: Florian Weimer, Senkevich, Andrew, Andreas Schwab, GNU C Library

On 01/24/2018 05:09 PM, H.J. Lu wrote:
> On Wed, Jan 24, 2018 at 4:32 PM, Carlos O'Donell <carlos@redhat.com> wrote:
>> On 01/24/2018 10:23 AM, Florian Weimer wrote:
>>> On 01/24/2018 07:08 PM, H.J. Lu wrote:
>>>> We opened a bug:
>>>>
>>>> https://sourceware.org/bugzilla/show_bug.cgi?id=22743
>>>>
>>>> Any help to track down the root cause is appreciated.
>>>
>>> Doesn't the bug report clearly show the root cause?  The offset of
>>> priv.data.cleanup changed, and old binaries have an insufficiently
>>> large stack allocation for the new offset.
>>>
>>> (Congratulations for tracking it down, by the way.  I know that such
>>> bugs are hard.)
>>>
>>> You need to add a symbol version for pthread_register_cancel.  It's
>>> too late for that now, so I recommend reverting the faulty commit.
>>
>> I have finished analyzing this and debugging the root cause myself,
>> and I agree with Florian, we need to revert:
>>
>> commit f81ddabffd76ac9dd600b02adbf3e1dac4bb10ec
>> commit cba595c350e52194e10c0006732e1991e3d0803b
>>
>> At a minimum. I am testing with them reverted locally.
>>
>> To be honest I'm surprised that this passed review and was checked
>> in, because the __pthread_unwind_buf_t has only at most 4-bytes of
>> space left before it is an ABI change. In the future please ping
>> me if you have any doubts and I'll review.
>>
>> The addition of __sigset_t saved_mask moves pthread_unwind_buf's
>> priv.data.cleanup forward by 124-bytes. The on-stack allocation of
>> the pthread_cleanup_push's __pthread_unwind_buf_t is not that big
>> and so __pthread_register_cancel writes to other structures which
>> are allocated on the stack.
>>
>> You cannot expand struct pthread_unwind_buf because the on-stack
>> allocated __pthread_unwind_buf_t is not large enough in existing
>> applications.
>>
>> You *might* have used feature_1 to change between two different
>> layouts of struct pthread_unwind_buf, but that will have to wait
>> for 2.28. As Florian suggests though it is cleaner to version
>> __pthread_register_cancel for x86 and the older version expects
>> the smaller non-CET-enabled structure.
>>
> 
> I will try to fix it by next Monday.
 
I will be reverting these changes in the next 24 hours.

They have a directly proven negative ABI consequences and will be
removed as soon as I finish validation that the reverted patches
are functional and pass the expected tests.

On Monday when you have a full fix ready we can discuss this with 
Dmitry Levin and the other developers to see if everyone agrees
that the solution is acceptable risk for 2.27.

-- 
Cheers,
Carlos.

^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: [PATCH 1/2] Linux/x86: Update cancel_jmp_buf to match __jmp_buf_tag [BZ #22563]
  2018-01-25  1:09                                                       ` H.J. Lu
  2018-01-25  1:44                                                         ` Carlos O'Donell
@ 2018-01-25  1:48                                                         ` Dmitry V. Levin
  2018-01-25  4:53                                                           ` [PATCH] Revert Intel CET changes to __jmp_buf_tag (Bug 22743) Carlos O'Donell
  1 sibling, 1 reply; 63+ messages in thread
From: Dmitry V. Levin @ 2018-01-25  1:48 UTC (permalink / raw)
  To: H.J. Lu
  Cc: Carlos O'Donell, Florian Weimer, Senkevich, Andrew,
	Andreas Schwab, GNU C Library

[-- Attachment #1: Type: text/plain, Size: 2398 bytes --]

On Wed, Jan 24, 2018 at 05:09:39PM -0800, H.J. Lu wrote:
> On Wed, Jan 24, 2018 at 4:32 PM, Carlos O'Donell <carlos@redhat.com> wrote:
> > On 01/24/2018 10:23 AM, Florian Weimer wrote:
> >> On 01/24/2018 07:08 PM, H.J. Lu wrote:
> >>> We opened a bug:
> >>>
> >>> https://sourceware.org/bugzilla/show_bug.cgi?id=22743
> >>>
> >>> Any help to track down the root cause is appreciated.
> >>
> >> Doesn't the bug report clearly show the root cause?  The offset of
> >> priv.data.cleanup changed, and old binaries have an insufficiently
> >> large stack allocation for the new offset.
> >>
> >> (Congratulations for tracking it down, by the way.  I know that such
> >> bugs are hard.)
> >>
> >> You need to add a symbol version for pthread_register_cancel.  It's
> >> too late for that now, so I recommend reverting the faulty commit.
> >
> > I have finished analyzing this and debugging the root cause myself,
> > and I agree with Florian, we need to revert:
> >
> > commit f81ddabffd76ac9dd600b02adbf3e1dac4bb10ec
> > commit cba595c350e52194e10c0006732e1991e3d0803b
> >
> > At a minimum. I am testing with them reverted locally.
> >
> > To be honest I'm surprised that this passed review and was checked
> > in, because the __pthread_unwind_buf_t has only at most 4-bytes of
> > space left before it is an ABI change. In the future please ping
> > me if you have any doubts and I'll review.
> >
> > The addition of __sigset_t saved_mask moves pthread_unwind_buf's
> > priv.data.cleanup forward by 124-bytes. The on-stack allocation of
> > the pthread_cleanup_push's __pthread_unwind_buf_t is not that big
> > and so __pthread_register_cancel writes to other structures which
> > are allocated on the stack.
> >
> > You cannot expand struct pthread_unwind_buf because the on-stack
> > allocated __pthread_unwind_buf_t is not large enough in existing
> > applications.
> >
> > You *might* have used feature_1 to change between two different
> > layouts of struct pthread_unwind_buf, but that will have to wait
> > for 2.28. As Florian suggests though it is cleaner to version
> > __pthread_register_cancel for x86 and the older version expects
> > the smaller non-CET-enabled structure.
> 
> I will try to fix it by next Monday.

I'm afraid by Monday it will be too late for 2.27 as we will get very
little testing before the release.


-- 
ldv

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

^ permalink raw reply	[flat|nested] 63+ messages in thread

* [PATCH] Revert Intel CET changes to __jmp_buf_tag (Bug 22743)
  2018-01-25  1:48                                                         ` Dmitry V. Levin
@ 2018-01-25  4:53                                                           ` Carlos O'Donell
  2018-01-25  5:33                                                             ` H.J. Lu
  0 siblings, 1 reply; 63+ messages in thread
From: Carlos O'Donell @ 2018-01-25  4:53 UTC (permalink / raw)
  To: H.J. Lu, Florian Weimer, Senkevich, Andrew, Andreas Schwab,
	GNU C Library

[-- Attachment #1: Type: text/plain, Size: 2115 bytes --]

On 01/24/2018 05:48 PM, Dmitry V. Levin wrote:
> I'm afraid by Monday it will be too late for 2.27 as we will get very
> little testing before the release.
 Before reverting:

[carlos@athas tst-cleanup1]$ /home/carlos/build/glibc/elf/ld.so --library-path /home/carlos/build/glibc:/home/carlos/build/glibc/elf:/home/carlos/build/glibc/dlfcn:/home/carlos/build/glibc/nptl ./tst-cleanup1
ch (3)
ch (2)
ch (1)
Didn't expect signal from child: got `Segmentation fault'

After reverting:

[carlos@athas tst-cleanup1]$ /home/carlos/build/glibc-reverted/elf/ld.so --library-path /home/carlos/build/glibc-reverted:/home/carlos/build/glibc-reverted/elf:/home/carlos/build/glibc-reverted/dlfcn:/home/carlos/build/glibc-reverted/nptl ./tst-cleanup1
ch (3)
ch (2)
ch (1)

~~~ Commit message ~~~
In commit cba595c350e52194e10c0006732e1991e3d0803b and commit
f81ddabffd76ac9dd600b02adbf3e1dac4bb10ec, ABI compatibility with
applications was broken by increasing the size of the on-stack
allocated __pthread_unwind_buf_t beyond the oringal size.
Applications only have the origianl space available for
__pthread_unwind_register, and __pthread_unwind_next to use,
any increase in the size of __pthread_unwind_buf_t causes these
functions to write beyond the original structure into other
on-stack variables leading to segmentation faults in common
applications like vlc. The only workaround is to version those
functions which operate on the old sized objects, but this must
happen in glibc 2.28.

Thank you to Andrew Senkevich, H.J. Lu, and Aurelien Jarno, for
submitting reports and tracking the issue down.

The commit reverts the above mentioned commits and testing on
x86_64 shows that the ABI compatibility is restored. A tst-cleanup1
regression test linked with an older glibc now passes when run
with the newly built glibc. Previously a tst-cleanup1 linked with
an older glibc would segfault when run with an affected glibc build.

Tested on x86_64 with no regressions.

Signed-off-by: Carlos O'Donell <carlos@redhat.com>
~~~

Patch attached.

OK to commit?

This fixes the last blocker for glibc 2.27.

-- 
Cheers,
Carlos.

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Revert-Intel-CET-changes-to-__jmp_buf_tag-Bug-22743.patch --]
[-- Type: text/x-patch; name="0001-Revert-Intel-CET-changes-to-__jmp_buf_tag-Bug-22743.patch", Size: 13712 bytes --]

From 440f414842b61923dc8219b26df10d2a12de0f82 Mon Sep 17 00:00:00 2001
From: Carlos O'Donell <carlos@systemhalted.org>
Date: Wed, 24 Jan 2018 20:35:22 -0800
Subject: [PATCH] Revert Intel CET changes to __jmp_buf_tag (Bug 22743)

In commit cba595c350e52194e10c0006732e1991e3d0803b and commit
f81ddabffd76ac9dd600b02adbf3e1dac4bb10ec, ABI compatibility with
applications was broken by increasing the size of the on-stack
allocated __pthread_unwind_buf_t beyond the oringal size.
Applications only have the origianl space available for
__pthread_unwind_register, and __pthread_unwind_next to use,
any increase in the size of __pthread_unwind_buf_t causes these
functions to write beyond the original structure into other
on-stack variables leading to segmentation faults in common
applications like vlc. The only workaround is to version those
functions which operate on the old sized objects, but this must
happen in glibc 2.28.

Thank you to Andrew Senkevich, H.J. Lu, and Aurelien Jarno, for
submitting reports and tracking the issue down.

The commit reverts the above mentioned commits and testing on
x86_64 shows that the ABI compatibility is restored. A tst-cleanup1
regression test linked with an older glibc now passes when run
with the newly built glibc. Previously a tst-cleanup1 linked with
an older glibc would segfault when run with an affected glibc build.

Tested on x86_64 with no regressions.

Signed-off-by: Carlos O'Donell <carlos@redhat.com>
---
 ChangeLog                                          | 30 ++++++++++++++++++
 bits/types/__cancel_jmp_buf_tag.h                  | 28 -----------------
 nptl/Makefile                                      |  3 +-
 nptl/descr.h                                       |  3 --
 sysdeps/i386/nptl/tcb-offsets.sym                  |  1 -
 sysdeps/i386/nptl/tls.h                            |  4 ---
 sysdeps/nptl/pthread.h                             |  7 +++--
 sysdeps/unix/sysv/linux/hppa/pthread.h             |  7 +++--
 .../linux/x86/bits/types/__cancel_jmp_buf_tag.h    | 31 -------------------
 sysdeps/unix/sysv/linux/x86/nptl/pthreadP.h        | 36 ----------------------
 sysdeps/unix/sysv/linux/x86/pthreaddef.h           | 22 -------------
 sysdeps/x86_64/nptl/tcb-offsets.sym                |  1 -
 sysdeps/x86_64/nptl/tls.h                          |  5 +--
 13 files changed, 42 insertions(+), 136 deletions(-)
 delete mode 100644 bits/types/__cancel_jmp_buf_tag.h
 delete mode 100644 sysdeps/unix/sysv/linux/x86/bits/types/__cancel_jmp_buf_tag.h
 delete mode 100644 sysdeps/unix/sysv/linux/x86/nptl/pthreadP.h
 delete mode 100644 sysdeps/unix/sysv/linux/x86/pthreaddef.h

diff --git a/ChangeLog b/ChangeLog
index 002839213f..fb287d8e75 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,33 @@
+2018-01-24  Carlos O'Donll  <carlos@redhat.com>
+
+	Revert:
+
+	2017-12-19  H.J. Lu  <hongjiu.lu@intel.com>
+
+	[BZ #22563]
+	* sysdeps/i386/nptl/tcb-offsets.sym (FEATURE_1_OFFSET): New.
+	* sysdeps/i386/nptl/tls.h (tcbhead_t): Add feature_1.
+	* sysdeps/x86_64/nptl/tcb-offsets.sym (FEATURE_1_OFFSET): New.
+	* sysdeps/x86_64/nptl/tls.h (tcbhead_t): Rename __glibc_unused1
+	to feature_1.
+
+	2017-12-19  H.J. Lu  <hongjiu.lu@intel.com>
+
+	[BZ #22563]
+	* bits/types/__cancel_jmp_buf_tag.h: New file.
+	* sysdeps/unix/sysv/linux/x86/bits/types/__cancel_jmp_buf_tag.h
+	* sysdeps/unix/sysv/linux/x86/pthreaddef.h: Likewise.
+	* sysdeps/unix/sysv/linux/x86/nptl/pthreadP.h: Likewise.
+	* nptl/Makefile (headers): Add
+	bits/types/__cancel_jmp_buf_tag.h.
+	* nptl/descr.h [NEED_SAVED_MASK_IN_CANCEL_JMP_BUF]
+	(pthread_unwind_buf): Add saved_mask to cancel_jmp_buf.
+	* sysdeps/nptl/pthread.h: Include
+	<bits/types/__cancel_jmp_buf_tag.h>.
+	(__pthread_unwind_buf_t): Use struct __cancel_jmp_buf_tag with
+	__cancel_jmp_buf.
+	* sysdeps/unix/sysv/linux/hppa/pthread.h: Likewise.
+
 2018-01-24  Joseph Myers  <joseph@codesourcery.com>
 
 	* sysdeps/unix/sysv/linux/m68k/jmp_buf-macros.h: Move to ....
diff --git a/bits/types/__cancel_jmp_buf_tag.h b/bits/types/__cancel_jmp_buf_tag.h
deleted file mode 100644
index 62f5c61f83..0000000000
--- a/bits/types/__cancel_jmp_buf_tag.h
+++ /dev/null
@@ -1,28 +0,0 @@
-/* Define struct __cancel_jmp_buf_tag.
-   Copyright (C) 2017-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/>.  */
-
-#ifndef ____cancel_jmp_buf_tag_defined
-#define ____cancel_jmp_buf_tag_defined 1
-
-struct __cancel_jmp_buf_tag
-  {
-    __jmp_buf __cancel_jmp_buf;
-    int __mask_was_saved;
-  };
-
-#endif
diff --git a/nptl/Makefile b/nptl/Makefile
index 7940b3d26b..6fc2c8bb6a 100644
--- a/nptl/Makefile
+++ b/nptl/Makefile
@@ -22,8 +22,7 @@ subdir	:= nptl
 
 include ../Makeconfig
 
-headers := pthread.h semaphore.h bits/semaphore.h \
-	   bits/types/__cancel_jmp_buf_tag.h
+headers := pthread.h semaphore.h bits/semaphore.h
 
 extra-libs := libpthread
 extra-libs-others := $(extra-libs)
diff --git a/nptl/descr.h b/nptl/descr.h
index 1cc6b09d1e..64ba29e1cb 100644
--- a/nptl/descr.h
+++ b/nptl/descr.h
@@ -65,9 +65,6 @@ struct pthread_unwind_buf
   {
     __jmp_buf jmp_buf;
     int mask_was_saved;
-#ifdef NEED_SAVED_MASK_IN_CANCEL_JMP_BUF
-    __sigset_t saved_mask;
-#endif
   } cancel_jmp_buf[1];
 
   union
diff --git a/sysdeps/i386/nptl/tcb-offsets.sym b/sysdeps/i386/nptl/tcb-offsets.sym
index 250f1a6e13..695a810386 100644
--- a/sysdeps/i386/nptl/tcb-offsets.sym
+++ b/sysdeps/i386/nptl/tcb-offsets.sym
@@ -15,4 +15,3 @@ POINTER_GUARD		offsetof (tcbhead_t, pointer_guard)
 #ifndef __ASSUME_PRIVATE_FUTEX
 PRIVATE_FUTEX		offsetof (tcbhead_t, private_futex)
 #endif
-FEATURE_1_OFFSET	offsetof (tcbhead_t, feature_1)
diff --git a/sysdeps/i386/nptl/tls.h b/sysdeps/i386/nptl/tls.h
index 30643d452a..fcda135b7c 100644
--- a/sysdeps/i386/nptl/tls.h
+++ b/sysdeps/i386/nptl/tls.h
@@ -50,10 +50,6 @@ typedef struct
   void *__private_tm[4];
   /* GCC split stack support.  */
   void *__private_ss;
-  /* Bit 0: IBT.
-     Bit 1: SHSTK.
-   */
-  unsigned int feature_1;
 } tcbhead_t;
 
 # define TLS_MULTIPLE_THREADS_IN_TCB 1
diff --git a/sysdeps/nptl/pthread.h b/sysdeps/nptl/pthread.h
index c8ba5a75c5..df049abf74 100644
--- a/sysdeps/nptl/pthread.h
+++ b/sysdeps/nptl/pthread.h
@@ -27,7 +27,6 @@
 #include <bits/setjmp.h>
 #include <bits/wordsize.h>
 #include <bits/types/struct_timespec.h>
-#include <bits/types/__cancel_jmp_buf_tag.h>
 
 
 /* Detach state.  */
@@ -524,7 +523,11 @@ extern void pthread_testcancel (void);
 
 typedef struct
 {
-  struct __cancel_jmp_buf_tag __cancel_jmp_buf[1];
+  struct
+  {
+    __jmp_buf __cancel_jmp_buf;
+    int __mask_was_saved;
+  } __cancel_jmp_buf[1];
   void *__pad[4];
 } __pthread_unwind_buf_t __attribute__ ((__aligned__));
 
diff --git a/sysdeps/unix/sysv/linux/hppa/pthread.h b/sysdeps/unix/sysv/linux/hppa/pthread.h
index 3df5e7c2ac..11a024db59 100644
--- a/sysdeps/unix/sysv/linux/hppa/pthread.h
+++ b/sysdeps/unix/sysv/linux/hppa/pthread.h
@@ -27,7 +27,6 @@
 #include <bits/setjmp.h>
 #include <bits/wordsize.h>
 #include <bits/types/struct_timespec.h>
-#include <bits/types/__cancel_jmp_buf_tag.h>
 
 
 /* Detach state.  */
@@ -500,7 +499,11 @@ extern void pthread_testcancel (void);
 
 typedef struct
 {
-  struct __cancel_jmp_buf_tag __cancel_jmp_buf[1];
+  struct
+  {
+    __jmp_buf __cancel_jmp_buf;
+    int __mask_was_saved;
+  } __cancel_jmp_buf[1];
   void *__pad[4];
 } __pthread_unwind_buf_t __attribute__ ((__aligned__));
 
diff --git a/sysdeps/unix/sysv/linux/x86/bits/types/__cancel_jmp_buf_tag.h b/sysdeps/unix/sysv/linux/x86/bits/types/__cancel_jmp_buf_tag.h
deleted file mode 100644
index 70efbb190c..0000000000
--- a/sysdeps/unix/sysv/linux/x86/bits/types/__cancel_jmp_buf_tag.h
+++ /dev/null
@@ -1,31 +0,0 @@
-/* Define struct __cancel_jmp_buf_tag.
-   Copyright (C) 2017-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/>.  */
-
-#ifndef ____cancel_jmp_buf_tag_defined
-#define ____cancel_jmp_buf_tag_defined 1
-
-#include <bits/types/__sigset_t.h>
-
-struct __cancel_jmp_buf_tag
-  {
-    __jmp_buf __cancel_jmp_buf;
-    int __mask_was_saved;
-    __sigset_t __saved_mask;
-  };
-
-#endif
diff --git a/sysdeps/unix/sysv/linux/x86/nptl/pthreadP.h b/sysdeps/unix/sysv/linux/x86/nptl/pthreadP.h
deleted file mode 100644
index 247a62e9a0..0000000000
--- a/sysdeps/unix/sysv/linux/x86/nptl/pthreadP.h
+++ /dev/null
@@ -1,36 +0,0 @@
-/* Internal pthread header.  Linux/x86 version.
-   Copyright (C) 2017-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/>.  */
-
-#include_next <nptl/pthreadP.h>
-
-#ifndef _PTHREADP_H_X86
-#define _PTHREADP_H_X86 1
-
-extern struct pthread_unwind_buf ____pthread_unwind_buf_private;
-
-_Static_assert (sizeof (____pthread_unwind_buf_private.cancel_jmp_buf)
-		>= sizeof (struct __jmp_buf_tag),
-		"size of cancel_jmp_buf < sizeof __jmp_buf_tag");
-
-extern __pthread_unwind_buf_t ____pthread_unwind_buf;
-
-_Static_assert (sizeof (____pthread_unwind_buf.__cancel_jmp_buf)
-		>= sizeof (struct __jmp_buf_tag),
-		"size of __cancel_jmp_buf < sizeof __jmp_buf_tag");
-
-#endif
diff --git a/sysdeps/unix/sysv/linux/x86/pthreaddef.h b/sysdeps/unix/sysv/linux/x86/pthreaddef.h
deleted file mode 100644
index a405a65666..0000000000
--- a/sysdeps/unix/sysv/linux/x86/pthreaddef.h
+++ /dev/null
@@ -1,22 +0,0 @@
-/* Pthread macros.  Linux/x86 version.
-   Copyright (C) 2017-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/>.  */
-
-#include_next <pthreaddef.h>
-
-/* Need saved_mask in cancel_jmp_buf.  */
-#define NEED_SAVED_MASK_IN_CANCEL_JMP_BUF 1
diff --git a/sysdeps/x86_64/nptl/tcb-offsets.sym b/sysdeps/x86_64/nptl/tcb-offsets.sym
index 03b6dba5c3..8a25c482cb 100644
--- a/sysdeps/x86_64/nptl/tcb-offsets.sym
+++ b/sysdeps/x86_64/nptl/tcb-offsets.sym
@@ -15,7 +15,6 @@ VGETCPU_CACHE_OFFSET	offsetof (tcbhead_t, vgetcpu_cache)
 #ifndef __ASSUME_PRIVATE_FUTEX
 PRIVATE_FUTEX		offsetof (tcbhead_t, private_futex)
 #endif
-FEATURE_1_OFFSET	offsetof (tcbhead_t, feature_1)
 
 -- Not strictly offsets, but these values are also used in the TCB.
 TCB_CANCELSTATE_BITMASK	 CANCELSTATE_BITMASK
diff --git a/sysdeps/x86_64/nptl/tls.h b/sysdeps/x86_64/nptl/tls.h
index 7f0b292f42..bdd02376f9 100644
--- a/sysdeps/x86_64/nptl/tls.h
+++ b/sysdeps/x86_64/nptl/tls.h
@@ -56,10 +56,7 @@ typedef struct
 # else
   int __glibc_reserved1;
 # endif
-  /* Bit 0: IBT.
-     Bit 1: SHSTK.
-   */
-  unsigned int feature_1;
+  int __glibc_unused1;
   /* Reservation of some values for the TM ABI.  */
   void *__private_tm[4];
   /* GCC split stack support.  */
-- 
2.14.3


^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: [PATCH] Revert Intel CET changes to __jmp_buf_tag (Bug 22743)
  2018-01-25  4:53                                                           ` [PATCH] Revert Intel CET changes to __jmp_buf_tag (Bug 22743) Carlos O'Donell
@ 2018-01-25  5:33                                                             ` H.J. Lu
  2018-01-25  9:47                                                               ` Florian Weimer
  2018-01-25 16:37                                                               ` Carlos O'Donell
  0 siblings, 2 replies; 63+ messages in thread
From: H.J. Lu @ 2018-01-25  5:33 UTC (permalink / raw)
  To: Carlos O'Donell
  Cc: Florian Weimer, Senkevich, Andrew, Andreas Schwab, GNU C Library

On Wed, Jan 24, 2018 at 8:53 PM, Carlos O'Donell <carlos@redhat.com> wrote:
> On 01/24/2018 05:48 PM, Dmitry V. Levin wrote:
>> I'm afraid by Monday it will be too late for 2.27 as we will get very
>> little testing before the release.
>  Before reverting:
>
> [carlos@athas tst-cleanup1]$ /home/carlos/build/glibc/elf/ld.so --library-path /home/carlos/build/glibc:/home/carlos/build/glibc/elf:/home/carlos/build/glibc/dlfcn:/home/carlos/build/glibc/nptl ./tst-cleanup1
> ch (3)
> ch (2)
> ch (1)
> Didn't expect signal from child: got `Segmentation fault'
>
> After reverting:
>
> [carlos@athas tst-cleanup1]$ /home/carlos/build/glibc-reverted/elf/ld.so --library-path /home/carlos/build/glibc-reverted:/home/carlos/build/glibc-reverted/elf:/home/carlos/build/glibc-reverted/dlfcn:/home/carlos/build/glibc-reverted/nptl ./tst-cleanup1
> ch (3)
> ch (2)
> ch (1)
>
> ~~~ Commit message ~~~
> In commit cba595c350e52194e10c0006732e1991e3d0803b and commit
> f81ddabffd76ac9dd600b02adbf3e1dac4bb10ec, ABI compatibility with
> applications was broken by increasing the size of the on-stack
> allocated __pthread_unwind_buf_t beyond the oringal size.
> Applications only have the origianl space available for
> __pthread_unwind_register, and __pthread_unwind_next to use,
> any increase in the size of __pthread_unwind_buf_t causes these
> functions to write beyond the original structure into other
> on-stack variables leading to segmentation faults in common
> applications like vlc. The only workaround is to version those
> functions which operate on the old sized objects, but this must
> happen in glibc 2.28.
>
> Thank you to Andrew Senkevich, H.J. Lu, and Aurelien Jarno, for
> submitting reports and tracking the issue down.
>
> The commit reverts the above mentioned commits and testing on
> x86_64 shows that the ABI compatibility is restored. A tst-cleanup1
> regression test linked with an older glibc now passes when run
> with the newly built glibc. Previously a tst-cleanup1 linked with
> an older glibc would segfault when run with an affected glibc build.
>
> Tested on x86_64 with no regressions.
>
> Signed-off-by: Carlos O'Donell <carlos@redhat.com>
> ~~~
>
> Patch attached.
>
> OK to commit?
>
> This fixes the last blocker for glibc 2.27.

Please don't revert my patch.  Please try this patch:

https://sourceware.org/git/?p=glibc.git;a=commit;h=4b7fc470a6740808b41502d7431f91805e272d26

instead.  I will clean it up and submit it tomorrow.

Thanks.


-- 
H.J.

^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: [PATCH] Revert Intel CET changes to __jmp_buf_tag (Bug 22743)
  2018-01-25  5:33                                                             ` H.J. Lu
@ 2018-01-25  9:47                                                               ` Florian Weimer
  2018-01-25 12:38                                                                 ` H.J. Lu
  2018-01-25 16:37                                                               ` Carlos O'Donell
  1 sibling, 1 reply; 63+ messages in thread
From: Florian Weimer @ 2018-01-25  9:47 UTC (permalink / raw)
  To: H.J. Lu, Carlos O'Donell
  Cc: Senkevich, Andrew, Andreas Schwab, GNU C Library

On 01/25/2018 06:33 AM, H.J. Lu wrote:

> Please don't revert my patch.  Please try this patch:
> 
> https://sourceware.org/git/?p=glibc.git;a=commit;h=4b7fc470a6740808b41502d7431f91805e272d26
> 
> instead.  I will clean it up and submit it tomorrow.

I don't see how adding a symbol version to pthread_create helps to solve 
the general case.  Callers of pthread_register_cancel and pthread_create 
are often compiled at different times.  Not everyone does a mass rebuild 
each time they switch to a new glibc version.

I still think you are over-engineering this.  The pad array has still an 
unused member (the last one).  Just change sigsetjmp to store the shadow 
pointer in that location, then the old and new setjmp will work with the 
current stack layout.  As far as I can tell, there are only 64 signals, 
so you don't even have to change the location of the signal mask.

Furthermore, nothing in the toolchain prevents people from compiling 
CET-marked binaries with older glibc headers, so you can't use CET 
markup to determine the size of the stack allocation anyway.

Thanks,
Florian

^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: [PATCH] Revert Intel CET changes to __jmp_buf_tag (Bug 22743)
  2018-01-25  9:47                                                               ` Florian Weimer
@ 2018-01-25 12:38                                                                 ` H.J. Lu
  2018-01-25 12:50                                                                   ` Florian Weimer
  0 siblings, 1 reply; 63+ messages in thread
From: H.J. Lu @ 2018-01-25 12:38 UTC (permalink / raw)
  To: Florian Weimer
  Cc: Carlos O'Donell, Senkevich, Andrew, Andreas Schwab, GNU C Library

[-- Attachment #1: Type: text/plain, Size: 3084 bytes --]

On Thu, Jan 25, 2018 at 1:47 AM, Florian Weimer <fweimer@redhat.com> wrote:
> On 01/25/2018 06:33 AM, H.J. Lu wrote:
>
>> Please don't revert my patch.  Please try this patch:
>>
>>
>> https://sourceware.org/git/?p=glibc.git;a=commit;h=4b7fc470a6740808b41502d7431f91805e272d26
>>
>> instead.  I will clean it up and submit it tomorrow.
>
>
> I don't see how adding a symbol version to pthread_create helps to solve the
> general case.  Callers of pthread_register_cancel and pthread_create are
> often compiled at different times.  Not everyone does a mass rebuild each
> time they switch to a new glibc version.

True.  We just need to use the older struct pthread_unwind_buf when shadow
stack is disabled.

> I still think you are over-engineering this.  The pad array has still an
> unused member (the last one).  Just change sigsetjmp to store the shadow
> pointer in that location, then the old and new setjmp will work with the
> current stack layout.  As far as I can tell, there are only 64 signals, so
> you don't even have to change the location of the signal mask.

No, it doesn't work.  struct pthread_unwind_buf is placed on caller's stack
and its address is passed from applications to libpthread.   If the size of
caller's struct pthread_unwind_buf is smaller than what libpthread expects,
libpthread will override caller's stack.

> Furthermore, nothing in the toolchain prevents people from compiling

That is not true.  From CET spec:

https://github.com/hjl-tools/x86-psABI/wiki/x86-64-psABI-cet.pdf

On a SHSTK capable processor, the following steps should be taken:
1. When loading an executable without interpreter, enable and lock SHSTK if
GNU_PROPERTY_X86_FEATURE_1_SHSTK is set on the executable.
2. When loading an executable with an interpreter, enable SHSTK
if GNU_PROPERTY_X86_FEATURE_1_SHSTK is set on
the interpreter. The interpreter should disable SHSTK if
GNU_PROPERTY_X86_FEATURE_1_SHSTK isn’t set or any shared
objects loaded via the DT_NEEDED tag, otherwise lock SHSTK.
3. After SHSTK is enabled, it is an error to load a shared object without
GNU_PROPERTY_X86_FEATURE_1_SHSTK.

> CET-marked binaries with older glibc headers, so you can't use CET markup to
> determine the size of the stack allocation anyway.
>

Yes, we can.

We enable shadow stack at run-time only if program and all used shared
objects, including dlopened ones, are shadow stack enabled, which means
that they must be compiled with GCC 8 or above and glibc 2.27 or above.
Since we need to save and restore shadow stack only if shadow stack is
enabled, we can safely assume that caller is compiled with smaller
struct pthread_unwind_buf on stack if shadow stack isn't enabled at
run-time.  For callers with larger struct pthread_unwind_buf, but
shadow stack isn't enabled, we just have some unused space on caller's
stack.

Here is the patch to do that,  Andrew, please work with Debian to verify
that fixes the crash.

BTW, my patch is on hjl/pr22743/master branch in glibc git repo.

Thanks.

-- 
H.J.

[-- Attachment #2: 0001-nptl-Update-struct-pthread_unwind_buf-BZ-22743.patch --]
[-- Type: text/x-patch, Size: 13854 bytes --]

From 10bba58b7eece4eac0db07c100217b709efd4727 Mon Sep 17 00:00:00 2001
From: "H.J. Lu" <hjl.tools@gmail.com>
Date: Wed, 24 Jan 2018 15:27:49 -0800
Subject: [PATCH] nptl: Update struct pthread_unwind_buf [BZ #22743]

In glibc 2.27, the size of cancel_jmp_buf in struct pthread_unwind_buf
has been increased to match the size of __jmp_buf_tag on Linux/x86 in
order to save and restore shadow stack.  Struct pthread_unwind_buf is
used in <pthread.h>, whose address is passed from applications to
libpthread.  To access the private data in struct pthread_unwind_buf,
which is placed after cancel_jmp_buf, in libpthread, we must know which
struct pthread_unwind_buf, before glibc 27 and after glibc 2.27, is used
in caller.  If the size of caller's struct pthread_unwind_buf is smaller
than what libpthread expects, libpthread will override caller's stack
since struct pthread_unwind_buf is placed on caller's stack.

We enable shadow stack at run-time only if program and all used shared
objects, including dlopened ones, are shadow stack enabled, which means
that they must be compiled with GCC 8 or above and glibc 2.27 or above.
Since we need to save and restore shadow stack only if shadow stack is
enabled, we can safely assume that caller is compiled with smaller
struct pthread_unwind_buf on stack if shadow stack isn't enabled at
run-time.  For callers with larger struct pthread_unwind_buf, but
shadow stack isn't enabled, we just have some unused space on caller's
stack.

struct pthread_unwind_buf is changed to union of

1. struct cancel_jmp_buf[1], which contains the common fields of struct
updated_pthread_unwind_buf and struct compat_pthread_unwind_buf.
2. struct updated_pthread_unwind_buf, which is the updated layout of
the cleanup buffer.
3. struct compat_pthread_unwind_buf, which is the compatible layout of
the cleanup buffer.

A macro, UNWIND_BUF_PRIV, is added to get the pointer to the priv field.
By default, it uses the priv field of struct compat_pthread_unwind_buf.
If a target defines NEED_SAVED_MASK_IN_CANCEL_JMP_BUF, it must provide
its own version of UNEIND_BUF_PRIV to get the pointer to the priv field.
On Linux/x86, it uses the priv field of struct compat_pthread_unwind_buf
if shadow stack is disabled and struct updated_pthread_unwind_buf if
shadow stack is enabled.

	[BZ #22743]
	* csu/libc-start.c (LIBC_START_MAIN): Use the updated version
	of the cleanup buffer.
	* nptl/cleanup.c (__pthread_register_cancel): Use UNWIND_BUF_PRIV
	to access the priv field in the cleanup buffer.
	(__pthread_unregister_cancel): Likewise.
	* nptl/cleanup_defer.c (__pthread_register_cancel_defer):
	Likewise.
	(__pthread_unregister_cancel_restore): Likewise.
	* nptl/unwind.c (unwind_stop): Likewise.
	(__pthread_unwind_next): Likewise.
	* nptl/descr.h (pthread_unwind_buf_data): New.
	(updated_pthread_unwind_buf): Likewise.
	(compat_pthread_unwind_buf): Likewise.
	(pthread_unwind_buf): Updated to use updated_pthread_unwind_buf
	and compat_pthread_unwind_buf.
	(UNWIND_BUF_PRIV): New.  Macro to get pointer to the priv field
	in the cleanup buffer.
	* nptl/pthread_create.c (START_THREAD_DEFN): Use the updated
	version of the cleanup buffer.
	(__pthread_create_2_1): Use THREAD_COPY_ADDITONAL_INFO to copy
	additonal info if defined.
	* sysdeps/unix/sysv/linux/x86/nptl/pthreadP.h: Use the updated
	version of the cleanup buffer to check cancel_jmp_buf size.
	* sysdeps/unix/sysv/linux/x86/pthreaddef.h
	(THREAD_COPY_ADDITONAL_INFO): New.
	(UNWIND_BUF_PRIV): Likewise.
---
 csu/libc-start.c                            |  6 ++-
 nptl/cleanup.c                              | 10 ++--
 nptl/cleanup_defer.c                        | 18 ++++---
 nptl/descr.h                                | 75 ++++++++++++++++++++++-------
 nptl/pthread_create.c                       |  9 +++-
 nptl/unwind.c                               |  6 ++-
 sysdeps/unix/sysv/linux/x86/nptl/pthreadP.h |  2 +-
 sysdeps/unix/sysv/linux/x86/pthreaddef.h    | 14 ++++++
 8 files changed, 106 insertions(+), 34 deletions(-)

diff --git a/csu/libc-start.c b/csu/libc-start.c
index 605222fa3f..44333446f2 100644
--- a/csu/libc-start.c
+++ b/csu/libc-start.c
@@ -298,8 +298,10 @@ LIBC_START_MAIN (int (*main) (int, char **, char ** MAIN_AUXVEC_DECL),
       struct pthread *self = THREAD_SELF;
 
       /* Store old info.  */
-      unwind_buf.priv.data.prev = THREAD_GETMEM (self, cleanup_jmp_buf);
-      unwind_buf.priv.data.cleanup = THREAD_GETMEM (self, cleanup);
+      unwind_buf.updated.priv.data.prev
+	= THREAD_GETMEM (self, cleanup_jmp_buf);
+      unwind_buf.updated.priv.data.cleanup
+	= THREAD_GETMEM (self, cleanup);
 
       /* Store the new cleanup handler info.  */
       THREAD_SETMEM (self, cleanup_jmp_buf, &unwind_buf);
diff --git a/nptl/cleanup.c b/nptl/cleanup.c
index d21b86e88b..403ffc9fc5 100644
--- a/nptl/cleanup.c
+++ b/nptl/cleanup.c
@@ -28,8 +28,10 @@ __pthread_register_cancel (__pthread_unwind_buf_t *buf)
   struct pthread *self = THREAD_SELF;
 
   /* Store old info.  */
-  ibuf->priv.data.prev = THREAD_GETMEM (self, cleanup_jmp_buf);
-  ibuf->priv.data.cleanup = THREAD_GETMEM (self, cleanup);
+  UNWIND_BUF_PRIV (self, ibuf)->data.prev
+    = THREAD_GETMEM (self, cleanup_jmp_buf);
+  UNWIND_BUF_PRIV (self, ibuf)->data.cleanup
+    = THREAD_GETMEM (self, cleanup);
 
   /* Store the new cleanup handler info.  */
   THREAD_SETMEM (self, cleanup_jmp_buf, (struct pthread_unwind_buf *) buf);
@@ -42,7 +44,9 @@ __cleanup_fct_attribute
 __pthread_unregister_cancel (__pthread_unwind_buf_t *buf)
 {
   struct pthread_unwind_buf *ibuf = (struct pthread_unwind_buf *) buf;
+  struct pthread *self = THREAD_SELF;
 
-  THREAD_SETMEM (THREAD_SELF, cleanup_jmp_buf, ibuf->priv.data.prev);
+  THREAD_SETMEM (self, cleanup_jmp_buf,
+		 UNWIND_BUF_PRIV (self, ibuf)->data.prev);
 }
 hidden_def (__pthread_unregister_cancel)
diff --git a/nptl/cleanup_defer.c b/nptl/cleanup_defer.c
index 5701ce4213..20ace3272a 100644
--- a/nptl/cleanup_defer.c
+++ b/nptl/cleanup_defer.c
@@ -28,8 +28,10 @@ __pthread_register_cancel_defer (__pthread_unwind_buf_t *buf)
   struct pthread *self = THREAD_SELF;
 
   /* Store old info.  */
-  ibuf->priv.data.prev = THREAD_GETMEM (self, cleanup_jmp_buf);
-  ibuf->priv.data.cleanup = THREAD_GETMEM (self, cleanup);
+  UNWIND_BUF_PRIV (self, ibuf)->data.prev
+    = THREAD_GETMEM (self, cleanup_jmp_buf);
+  UNWIND_BUF_PRIV (self, ibuf)->data.cleanup
+    = THREAD_GETMEM (self, cleanup);
 
   int cancelhandling = THREAD_GETMEM (self, cancelhandling);
 
@@ -49,9 +51,9 @@ __pthread_register_cancel_defer (__pthread_unwind_buf_t *buf)
 	cancelhandling = curval;
       }
 
-  ibuf->priv.data.canceltype = (cancelhandling & CANCELTYPE_BITMASK
-				? PTHREAD_CANCEL_ASYNCHRONOUS
-				: PTHREAD_CANCEL_DEFERRED);
+  UNWIND_BUF_PRIV (self, ibuf)->data.canceltype
+    = (cancelhandling & CANCELTYPE_BITMASK
+       ? PTHREAD_CANCEL_ASYNCHRONOUS : PTHREAD_CANCEL_DEFERRED);
 
   /* Store the new cleanup handler info.  */
   THREAD_SETMEM (self, cleanup_jmp_buf, (struct pthread_unwind_buf *) buf);
@@ -65,10 +67,12 @@ __pthread_unregister_cancel_restore (__pthread_unwind_buf_t *buf)
   struct pthread *self = THREAD_SELF;
   struct pthread_unwind_buf *ibuf = (struct pthread_unwind_buf *) buf;
 
-  THREAD_SETMEM (self, cleanup_jmp_buf, ibuf->priv.data.prev);
+  THREAD_SETMEM (self, cleanup_jmp_buf,
+		 UNWIND_BUF_PRIV (self, ibuf)->data.prev);
 
   int cancelhandling;
-  if (ibuf->priv.data.canceltype != PTHREAD_CANCEL_DEFERRED
+  if ((UNWIND_BUF_PRIV (self, ibuf)->data.canceltype
+       != PTHREAD_CANCEL_DEFERRED)
       && ((cancelhandling = THREAD_GETMEM (self, cancelhandling))
 	  & CANCELTYPE_BITMASK) == 0)
     {
diff --git a/nptl/descr.h b/nptl/descr.h
index 1cc6b09d1e..a30d4fe010 100644
--- a/nptl/descr.h
+++ b/nptl/descr.h
@@ -55,11 +55,30 @@
    / PTHREAD_KEY_2NDLEVEL_SIZE)
 
 
+/* Private data in the cleanup buffer.  */
+union pthread_unwind_buf_data
+{
+  /* This is the placeholder of the public version.  */
+  void *pad[4];
+
+ struct
+  {
+    /* Pointer to the previous cleanup buffer.  */
+    struct pthread_unwind_buf *prev;
 
+    /* Backward compatibility: state of the old-style cleanup
+       handler at the time of the previous new-style cleanup handler
+       installment.  */
+    struct _pthread_cleanup_buffer *cleanup;
 
-/* Internal version of the buffer to store cancellation handler
+    /* Cancellation type before the push call.  */
+    int canceltype;
+  } data;
+};
+
+/* Internal updated version of the buffer to store cancellation handler
    information.  */
-struct pthread_unwind_buf
+struct updated_pthread_unwind_buf
 {
   struct
   {
@@ -70,27 +89,49 @@ struct pthread_unwind_buf
 #endif
   } cancel_jmp_buf[1];
 
-  union
+  union pthread_unwind_buf_data priv;
+};
+
+/* Internal compatible version of the buffer to store cancellation
+   handler information.  */
+struct compat_pthread_unwind_buf
+{
+  struct
   {
-    /* This is the placeholder of the public version.  */
-    void *pad[4];
+    __jmp_buf jmp_buf;
+    int mask_was_saved;
+  } cancel_jmp_buf[1];
+
+  union pthread_unwind_buf_data priv;
+};
 
+/* Internal version of the buffer to store cancellation handler
+   information.  */
+struct pthread_unwind_buf
+{
+  union
+  {
+    /* The common fields of updated and compatible versions.  */
     struct
     {
-      /* Pointer to the previous cleanup buffer.  */
-      struct pthread_unwind_buf *prev;
-
-      /* Backward compatibility: state of the old-style cleanup
-	 handler at the time of the previous new-style cleanup handler
-	 installment.  */
-      struct _pthread_cleanup_buffer *cleanup;
-
-      /* Cancellation type before the push call.  */
-      int canceltype;
-    } data;
-  } priv;
+      __jmp_buf jmp_buf;
+      int mask_was_saved;
+    } cancel_jmp_buf[1];
+    struct updated_pthread_unwind_buf updated;
+    struct compat_pthread_unwind_buf compat;
+  };
 };
 
+/* Get pointer to the priv field from THREAD_SELF, "self", and pointer
+   to the cleanup buffer, "p".  By default, the compatible version is
+   used.  If a target defines NEED_SAVED_MASK_IN_CANCEL_JMP_BUF, it
+   must provide its own version of UNEIND_BUF_PRIV.  */
+#ifndef UNWIND_BUF_PRIV
+# ifdef NEED_SAVED_MASK_IN_CANCEL_JMP_BUF
+#  error "UNWIND_BUF_PRIV is undefined!"
+# endif
+# define UNWIND_BUF_PRIV(self,p) (&((p)->compat.priv))
+#endif
 
 /* Opcodes and data types for communication with the signal handler to
    change user/group IDs.  */
diff --git a/nptl/pthread_create.c b/nptl/pthread_create.c
index caaf07c134..77647dcbae 100644
--- a/nptl/pthread_create.c
+++ b/nptl/pthread_create.c
@@ -428,8 +428,8 @@ START_THREAD_DEFN
   struct pthread_unwind_buf unwind_buf;
 
   /* No previous handlers.  */
-  unwind_buf.priv.data.prev = NULL;
-  unwind_buf.priv.data.cleanup = NULL;
+  unwind_buf.updated.priv.data.prev = NULL;
+  unwind_buf.updated.priv.data.cleanup = NULL;
 
   int not_first_call;
   not_first_call = setjmp ((struct __jmp_buf_tag *) unwind_buf.cancel_jmp_buf);
@@ -701,6 +701,11 @@ __pthread_create_2_1 (pthread_t *newthread, const pthread_attr_t *attr,
   THREAD_COPY_POINTER_GUARD (pd);
 #endif
 
+  /* Copy additonal info.  */
+#ifdef THREAD_COPY_ADDITONAL_INFO
+  THREAD_COPY_ADDITONAL_INFO (pd);
+#endif
+
   /* Verify the sysinfo bits were copied in allocate_stack if needed.  */
 #ifdef NEED_DL_SYSINFO
   CHECK_THREAD_SYSINFO (pd);
diff --git a/nptl/unwind.c b/nptl/unwind.c
index b37a063c53..f58be0ee5f 100644
--- a/nptl/unwind.c
+++ b/nptl/unwind.c
@@ -66,7 +66,8 @@ unwind_stop (int version, _Unwind_Action actions,
       /* Handle the compatibility stuff.  Execute all handlers
 	 registered with the old method which would be unwound by this
 	 step.  */
-      struct _pthread_cleanup_buffer *oldp = buf->priv.data.cleanup;
+      struct _pthread_cleanup_buffer *oldp
+	= UNWIND_BUF_PRIV (self, buf)->data.cleanup;
       void *cfa = (void *) (_Unwind_Ptr) _Unwind_GetCFA (context);
 
       if (curp != oldp && (do_longjump || FRAME_LEFT (cfa, curp, adj)))
@@ -133,6 +134,7 @@ __pthread_unwind_next (__pthread_unwind_buf_t *buf)
 {
   struct pthread_unwind_buf *ibuf = (struct pthread_unwind_buf *) buf;
 
-  __pthread_unwind ((__pthread_unwind_buf_t *) ibuf->priv.data.prev);
+  __pthread_unwind ((__pthread_unwind_buf_t *)
+		    UNWIND_BUF_PRIV (THREAD_SELF, ibuf)->data.prev);
 }
 hidden_def (__pthread_unwind_next)
diff --git a/sysdeps/unix/sysv/linux/x86/nptl/pthreadP.h b/sysdeps/unix/sysv/linux/x86/nptl/pthreadP.h
index 247a62e9a0..a3076bf980 100644
--- a/sysdeps/unix/sysv/linux/x86/nptl/pthreadP.h
+++ b/sysdeps/unix/sysv/linux/x86/nptl/pthreadP.h
@@ -23,7 +23,7 @@
 
 extern struct pthread_unwind_buf ____pthread_unwind_buf_private;
 
-_Static_assert (sizeof (____pthread_unwind_buf_private.cancel_jmp_buf)
+_Static_assert (sizeof (____pthread_unwind_buf_private.updated.cancel_jmp_buf)
 		>= sizeof (struct __jmp_buf_tag),
 		"size of cancel_jmp_buf < sizeof __jmp_buf_tag");
 
diff --git a/sysdeps/unix/sysv/linux/x86/pthreaddef.h b/sysdeps/unix/sysv/linux/x86/pthreaddef.h
index a405a65666..899fcd6743 100644
--- a/sysdeps/unix/sysv/linux/x86/pthreaddef.h
+++ b/sysdeps/unix/sysv/linux/x86/pthreaddef.h
@@ -20,3 +20,17 @@
 
 /* Need saved_mask in cancel_jmp_buf.  */
 #define NEED_SAVED_MASK_IN_CANCEL_JMP_BUF 1
+
+/* Wee need to copy feature_1 in pthread_create.  */
+#define THREAD_COPY_ADDITONAL_INFO(descr)				\
+  ((descr)->header.feature_1						\
+   = THREAD_GETMEM (THREAD_SELF, header.feature_1))
+
+/* Use the compatible struct __cancel_jmp_buf_tag if shadow stack is
+   disabled.  */
+#undef UNWIND_BUF_PRIV
+#define UNWIND_BUF_PRIV(self,p) \
+  (__extension__ ({							\
+     unsigned int feature_1 = THREAD_GETMEM (self, header.feature_1);	\
+     (((feature_1 & (1 << 1)) == 0)					\
+      ? &((p)->compat.priv) : &((p)->updated.priv));}))
-- 
2.14.3


^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: [PATCH] Revert Intel CET changes to __jmp_buf_tag (Bug 22743)
  2018-01-25 12:38                                                                 ` H.J. Lu
@ 2018-01-25 12:50                                                                   ` Florian Weimer
  2018-01-25 13:00                                                                     ` H.J. Lu
  2018-01-25 19:21                                                                     ` H.J. Lu
  0 siblings, 2 replies; 63+ messages in thread
From: Florian Weimer @ 2018-01-25 12:50 UTC (permalink / raw)
  To: H.J. Lu
  Cc: Carlos O'Donell, Senkevich, Andrew, Andreas Schwab, GNU C Library

On 01/25/2018 01:38 PM, H.J. Lu wrote:
>> I still think you are over-engineering this.  The pad array has still an
>> unused member (the last one).  Just change sigsetjmp to store the shadow
>> pointer in that location, then the old and new setjmp will work with the
>> current stack layout.  As far as I can tell, there are only 64 signals, so
>> you don't even have to change the location of the signal mask.
> No, it doesn't work.  struct pthread_unwind_buf is placed on caller's stack
> and its address is passed from applications to libpthread.   If the size of
> caller's struct pthread_unwind_buf is smaller than what libpthread expects,
> libpthread will override caller's stack.

As far as I can see, ibuf->priv.pad[3] is currently unused.  (sig)setjmp 
could save the shadow stack pointer at the right offset in jmp_buf to 
hit this place, then all these new conditionals wouldn't be necessary. 
Of course it is still a hack, but your approach is not clearer IMHO.

The patch you posted is very different from the commit link you shared 
earlier.  I still need to review it in detail.

Thanks,
Florian

^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: [PATCH] Revert Intel CET changes to __jmp_buf_tag (Bug 22743)
  2018-01-25 12:50                                                                   ` Florian Weimer
@ 2018-01-25 13:00                                                                     ` H.J. Lu
  2018-01-25 14:56                                                                       ` Zack Weinberg
  2018-01-25 19:21                                                                     ` H.J. Lu
  1 sibling, 1 reply; 63+ messages in thread
From: H.J. Lu @ 2018-01-25 13:00 UTC (permalink / raw)
  To: Florian Weimer
  Cc: Carlos O'Donell, Senkevich, Andrew, Andreas Schwab, GNU C Library

On Thu, Jan 25, 2018 at 4:50 AM, Florian Weimer <fweimer@redhat.com> wrote:
> On 01/25/2018 01:38 PM, H.J. Lu wrote:
>>>
>>> I still think you are over-engineering this.  The pad array has still an
>>> unused member (the last one).  Just change sigsetjmp to store the shadow
>>> pointer in that location, then the old and new setjmp will work with the
>>> current stack layout.  As far as I can tell, there are only 64 signals,
>>> so
>>> you don't even have to change the location of the signal mask.
>>
>> No, it doesn't work.  struct pthread_unwind_buf is placed on caller's
>> stack
>> and its address is passed from applications to libpthread.   If the size
>> of
>> caller's struct pthread_unwind_buf is smaller than what libpthread
>> expects,
>> libpthread will override caller's stack.
>
>
> As far as I can see, ibuf->priv.pad[3] is currently unused.  (sig)setjmp
> could save the shadow stack pointer at the right offset in jmp_buf to hit
> this place, then all these new conditionals wouldn't be necessary. Of course
> it is still a hack, but your approach is not clearer IMHO.

It is a mistake to use different jmpbuf sizes in libpthread and libc.
My patch is much more straightforward than what you suggested.
But I can live with it if everyone thinks it is the way to go.

> The patch you posted is very different from the commit link you shared
> earlier.  I still need to review it in detail.
>

Yes, I reworked the legacy cleanup buffer detection.  Now it simply checks
if shadow stack is enabled or not.

-- 
H.J.

^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: [PATCH] Revert Intel CET changes to __jmp_buf_tag (Bug 22743)
  2018-01-25 13:00                                                                     ` H.J. Lu
@ 2018-01-25 14:56                                                                       ` Zack Weinberg
  2018-01-25 15:33                                                                         ` H.J. Lu
  2018-01-25 18:26                                                                         ` Joseph Myers
  0 siblings, 2 replies; 63+ messages in thread
From: Zack Weinberg @ 2018-01-25 14:56 UTC (permalink / raw)
  To: H.J. Lu
  Cc: Florian Weimer, Carlos O'Donell, Senkevich, Andrew,
	Andreas Schwab, GNU C Library

On Thu, Jan 25, 2018 at 8:00 AM, H.J. Lu <hjl.tools@gmail.com> wrote:
> On Thu, Jan 25, 2018 at 4:50 AM, Florian Weimer <fweimer@redhat.com> wrote:
>> On 01/25/2018 01:38 PM, H.J. Lu wrote:
>>>>
>>>> I still think you are over-engineering this.  The pad array has still an
>>>> unused member (the last one).  Just change sigsetjmp to store the shadow
>>>> pointer in that location, then the old and new setjmp will work with the
>>>> current stack layout.  As far as I can tell, there are only 64 signals,
>>>> so
>>>> you don't even have to change the location of the signal mask.
>>>
>>> No, it doesn't work.  struct pthread_unwind_buf is placed on caller's
>>> stack
>>> and its address is passed from applications to libpthread.   If the size
>>> of
>>> caller's struct pthread_unwind_buf is smaller than what libpthread
>>> expects,
>>> libpthread will override caller's stack.
>>
>>
>> As far as I can see, ibuf->priv.pad[3] is currently unused.  (sig)setjmp
>> could save the shadow stack pointer at the right offset in jmp_buf to hit
>> this place, then all these new conditionals wouldn't be necessary. Of course
>> it is still a hack, but your approach is not clearer IMHO.
>
> It is a mistake to use different jmpbuf sizes in libpthread and libc.
> My patch is much more straightforward than what you suggested.
> But I can live with it if everyone thinks it is the way to go.

In my opinion, the fact that you two are having this argument
reinforces Carlos' position: the original patch should be reverted and
we should figure out what to do in 2.28 when we're not under time
pressure.  HJ, do you have some concrete external reason why you must
have this new feature in 2.27?  If so, please tell us what it is.  To
me it doesn't seem urgent.

Also, this incident demonstrates that we need better testing of our
ABI backward compatibility guarantees.  Automation for taking all of
the test binaries from glibc-2.x and running them against lib*.so from
glibc-2.y (y > x), or something like that.  Probably Joseph is in the
best position to know how hard that would be.

zw

^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: [PATCH] Revert Intel CET changes to __jmp_buf_tag (Bug 22743)
  2018-01-25 14:56                                                                       ` Zack Weinberg
@ 2018-01-25 15:33                                                                         ` H.J. Lu
  2018-01-25 16:22                                                                           ` Zack Weinberg
  2018-01-25 18:26                                                                         ` Joseph Myers
  1 sibling, 1 reply; 63+ messages in thread
From: H.J. Lu @ 2018-01-25 15:33 UTC (permalink / raw)
  To: Zack Weinberg
  Cc: Florian Weimer, Carlos O'Donell, Senkevich, Andrew,
	Andreas Schwab, GNU C Library

On Thu, Jan 25, 2018 at 6:55 AM, Zack Weinberg <zackw@panix.com> wrote:
> On Thu, Jan 25, 2018 at 8:00 AM, H.J. Lu <hjl.tools@gmail.com> wrote:
>> On Thu, Jan 25, 2018 at 4:50 AM, Florian Weimer <fweimer@redhat.com> wrote:
>>> On 01/25/2018 01:38 PM, H.J. Lu wrote:
>>>>>
>>>>> I still think you are over-engineering this.  The pad array has still an
>>>>> unused member (the last one).  Just change sigsetjmp to store the shadow
>>>>> pointer in that location, then the old and new setjmp will work with the
>>>>> current stack layout.  As far as I can tell, there are only 64 signals,
>>>>> so
>>>>> you don't even have to change the location of the signal mask.
>>>>
>>>> No, it doesn't work.  struct pthread_unwind_buf is placed on caller's
>>>> stack
>>>> and its address is passed from applications to libpthread.   If the size
>>>> of
>>>> caller's struct pthread_unwind_buf is smaller than what libpthread
>>>> expects,
>>>> libpthread will override caller's stack.
>>>
>>>
>>> As far as I can see, ibuf->priv.pad[3] is currently unused.  (sig)setjmp
>>> could save the shadow stack pointer at the right offset in jmp_buf to hit
>>> this place, then all these new conditionals wouldn't be necessary. Of course
>>> it is still a hack, but your approach is not clearer IMHO.
>>
>> It is a mistake to use different jmpbuf sizes in libpthread and libc.
>> My patch is much more straightforward than what you suggested.
>> But I can live with it if everyone thinks it is the way to go.
>
> In my opinion, the fact that you two are having this argument
> reinforces Carlos' position: the original patch should be reverted and
> we should figure out what to do in 2.28 when we're not under time
> pressure.  HJ, do you have some concrete external reason why you must
> have this new feature in 2.27?  If so, please tell us what it is.  To
> me it doesn't seem urgent.

My question is if we are going to fix it at all.  If yes, why not 2.27.
Both approaches are opaque to users.  They can't tell the difference.


-- 
H.J.

^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: [PATCH] Revert Intel CET changes to __jmp_buf_tag (Bug 22743)
  2018-01-25 15:33                                                                         ` H.J. Lu
@ 2018-01-25 16:22                                                                           ` Zack Weinberg
  2018-01-25 16:28                                                                             ` H.J. Lu
  2018-01-25 16:47                                                                             ` Florian Weimer
  0 siblings, 2 replies; 63+ messages in thread
From: Zack Weinberg @ 2018-01-25 16:22 UTC (permalink / raw)
  To: H.J. Lu
  Cc: Florian Weimer, Carlos O'Donell, Senkevich, Andrew,
	Andreas Schwab, GNU C Library

On Thu, Jan 25, 2018 at 10:33 AM, H.J. Lu <hjl.tools@gmail.com> wrote:
> On Thu, Jan 25, 2018 at 6:55 AM, Zack Weinberg <zackw@panix.com> wrote:
>> In my opinion, the fact that you two are having this argument
>> reinforces Carlos' position: the original patch should be reverted and
>> we should figure out what to do in 2.28 when we're not under time
>> pressure.  HJ, do you have some concrete external reason why you must
>> have this new feature in 2.27?  If so, please tell us what it is.  To
>> me it doesn't seem urgent.
>
> My question is if we are going to fix it at all.  If yes, why not 2.27.
> Both approaches are opaque to users.  They can't tell the difference.

My concerns are entirely based on timing: specifically, you seem to be
in a rush to squeak under the 2.27 deadline.  Rushing leads to
mistakes.

This seems like the sort of thing that could reasonably be backported
to the release branch(es) ... *after* we have calmly, without rushing,
figured out the correct fix in mainline.

zw

^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: [PATCH] Revert Intel CET changes to __jmp_buf_tag (Bug 22743)
  2018-01-25 16:22                                                                           ` Zack Weinberg
@ 2018-01-25 16:28                                                                             ` H.J. Lu
  2018-01-25 16:36                                                                               ` Carlos O'Donell
  2018-01-25 16:47                                                                             ` Florian Weimer
  1 sibling, 1 reply; 63+ messages in thread
From: H.J. Lu @ 2018-01-25 16:28 UTC (permalink / raw)
  To: Zack Weinberg
  Cc: Florian Weimer, Carlos O'Donell, Senkevich, Andrew,
	Andreas Schwab, GNU C Library

On Thu, Jan 25, 2018 at 8:22 AM, Zack Weinberg <zackw@panix.com> wrote:
> On Thu, Jan 25, 2018 at 10:33 AM, H.J. Lu <hjl.tools@gmail.com> wrote:
>> On Thu, Jan 25, 2018 at 6:55 AM, Zack Weinberg <zackw@panix.com> wrote:
>>> In my opinion, the fact that you two are having this argument
>>> reinforces Carlos' position: the original patch should be reverted and
>>> we should figure out what to do in 2.28 when we're not under time
>>> pressure.  HJ, do you have some concrete external reason why you must
>>> have this new feature in 2.27?  If so, please tell us what it is.  To
>>> me it doesn't seem urgent.
>>
>> My question is if we are going to fix it at all.  If yes, why not 2.27.
>> Both approaches are opaque to users.  They can't tell the difference.
>
> My concerns are entirely based on timing: specifically, you seem to be
> in a rush to squeak under the 2.27 deadline.  Rushing leads to
> mistakes.

The main issue for this one is testcase.  Once a testcase is found, we
know how to avoid the issue.

> This seems like the sort of thing that could reasonably be backported
> to the release branch(es) ... *after* we have calmly, without rushing,
> figured out the correct fix in mainline.
>

I am fine with reverting my patch only on 2.27 branch, not on master.

-- 
H.J.

^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: [PATCH] Revert Intel CET changes to __jmp_buf_tag (Bug 22743)
  2018-01-25 16:28                                                                             ` H.J. Lu
@ 2018-01-25 16:36                                                                               ` Carlos O'Donell
  2018-01-25 16:40                                                                                 ` H.J. Lu
  0 siblings, 1 reply; 63+ messages in thread
From: Carlos O'Donell @ 2018-01-25 16:36 UTC (permalink / raw)
  To: H.J. Lu, Zack Weinberg
  Cc: Florian Weimer, Senkevich, Andrew, Andreas Schwab, GNU C Library

On 01/25/2018 08:28 AM, H.J. Lu wrote:
> On Thu, Jan 25, 2018 at 8:22 AM, Zack Weinberg <zackw@panix.com> wrote:
>> On Thu, Jan 25, 2018 at 10:33 AM, H.J. Lu <hjl.tools@gmail.com> wrote:
>>> On Thu, Jan 25, 2018 at 6:55 AM, Zack Weinberg <zackw@panix.com> wrote:
>>>> In my opinion, the fact that you two are having this argument
>>>> reinforces Carlos' position: the original patch should be reverted and
>>>> we should figure out what to do in 2.28 when we're not under time
>>>> pressure.  HJ, do you have some concrete external reason why you must
>>>> have this new feature in 2.27?  If so, please tell us what it is.  To
>>>> me it doesn't seem urgent.
>>>
>>> My question is if we are going to fix it at all.  If yes, why not 2.27.
>>> Both approaches are opaque to users.  They can't tell the difference.
>>
>> My concerns are entirely based on timing: specifically, you seem to be
>> in a rush to squeak under the 2.27 deadline.  Rushing leads to
>> mistakes.
> 
> The main issue for this one is testcase.  Once a testcase is found, we
> know how to avoid the issue.
> 
>> This seems like the sort of thing that could reasonably be backported
>> to the release branch(es) ... *after* we have calmly, without rushing,
>> figured out the correct fix in mainline.
>>
> 
> I am fine with reverting my patch only on 2.27 branch, not on master.
 
This does not make sense. The revert on master would last for as long as
you have to come up with a patch that works and everyone accepts and has
consensus.

You checked these patches in without consensus, and instead of waiting
or pinging for review, you checked them in.

For x86_64 there is no machine maintainer, it requires community consensus,
the port is too important not to get serious community review.

They changes had negative ABI consequences, and now you have several
people interested in making sure future patches don't break ABI.

You have drawn attention to this work and now you have to reach consensus 
on a solution for a primary architecture which is very important to all of
us in the downstream distributions. More time is required to make these
patches work.

I see no clear argument for why this needs to be in 2.27.

I will be reverting the patches in the next 8 hours.

-- 
Cheers,
Carlos.

^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: [PATCH] Revert Intel CET changes to __jmp_buf_tag (Bug 22743)
  2018-01-25  5:33                                                             ` H.J. Lu
  2018-01-25  9:47                                                               ` Florian Weimer
@ 2018-01-25 16:37                                                               ` Carlos O'Donell
  2018-01-25 16:38                                                                 ` Florian Weimer
  1 sibling, 1 reply; 63+ messages in thread
From: Carlos O'Donell @ 2018-01-25 16:37 UTC (permalink / raw)
  To: H.J. Lu; +Cc: Florian Weimer, Senkevich, Andrew, Andreas Schwab, GNU C Library

On 01/24/2018 09:33 PM, H.J. Lu wrote:
> On Wed, Jan 24, 2018 at 8:53 PM, Carlos O'Donell <carlos@redhat.com> wrote:
>> On 01/24/2018 05:48 PM, Dmitry V. Levin wrote:
>>> I'm afraid by Monday it will be too late for 2.27 as we will get very
>>> little testing before the release.
>>  Before reverting:
>>
>> [carlos@athas tst-cleanup1]$ /home/carlos/build/glibc/elf/ld.so --library-path /home/carlos/build/glibc:/home/carlos/build/glibc/elf:/home/carlos/build/glibc/dlfcn:/home/carlos/build/glibc/nptl ./tst-cleanup1
>> ch (3)
>> ch (2)
>> ch (1)
>> Didn't expect signal from child: got `Segmentation fault'
>>
>> After reverting:
>>
>> [carlos@athas tst-cleanup1]$ /home/carlos/build/glibc-reverted/elf/ld.so --library-path /home/carlos/build/glibc-reverted:/home/carlos/build/glibc-reverted/elf:/home/carlos/build/glibc-reverted/dlfcn:/home/carlos/build/glibc-reverted/nptl ./tst-cleanup1
>> ch (3)
>> ch (2)
>> ch (1)
>>
>> ~~~ Commit message ~~~
>> In commit cba595c350e52194e10c0006732e1991e3d0803b and commit
>> f81ddabffd76ac9dd600b02adbf3e1dac4bb10ec, ABI compatibility with
>> applications was broken by increasing the size of the on-stack
>> allocated __pthread_unwind_buf_t beyond the oringal size.
>> Applications only have the origianl space available for
>> __pthread_unwind_register, and __pthread_unwind_next to use,
>> any increase in the size of __pthread_unwind_buf_t causes these
>> functions to write beyond the original structure into other
>> on-stack variables leading to segmentation faults in common
>> applications like vlc. The only workaround is to version those
>> functions which operate on the old sized objects, but this must
>> happen in glibc 2.28.
>>
>> Thank you to Andrew Senkevich, H.J. Lu, and Aurelien Jarno, for
>> submitting reports and tracking the issue down.
>>
>> The commit reverts the above mentioned commits and testing on
>> x86_64 shows that the ABI compatibility is restored. A tst-cleanup1
>> regression test linked with an older glibc now passes when run
>> with the newly built glibc. Previously a tst-cleanup1 linked with
>> an older glibc would segfault when run with an affected glibc build.
>>
>> Tested on x86_64 with no regressions.
>>
>> Signed-off-by: Carlos O'Donell <carlos@redhat.com>
>> ~~~
>>
>> Patch attached.
>>
>> OK to commit?
>>
>> This fixes the last blocker for glibc 2.27.
> 
> Please don't revert my patch.  Please try this patch:
> 
> https://sourceware.org/git/?p=glibc.git;a=commit;h=4b7fc470a6740808b41502d7431f91805e272d26
> 
> instead.  I will clean it up and submit it tomorrow.

This is unacceptable. It adds a new symbol version and we froze the
ABI at the start of the month. You cannot work these fixes into 2.27
with a new symbol version, it must wait for 2.28.

-- 
Cheers,
Carlos.

^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: [PATCH] Revert Intel CET changes to __jmp_buf_tag (Bug 22743)
  2018-01-25 16:37                                                               ` Carlos O'Donell
@ 2018-01-25 16:38                                                                 ` Florian Weimer
  0 siblings, 0 replies; 63+ messages in thread
From: Florian Weimer @ 2018-01-25 16:38 UTC (permalink / raw)
  To: Carlos O'Donell, H.J. Lu
  Cc: Senkevich, Andrew, Andreas Schwab, GNU C Library

On 01/25/2018 05:37 PM, Carlos O'Donell wrote:
>> Please don't revert my patch.  Please try this patch:
>>
>> https://sourceware.org/git/?p=glibc.git;a=commit;h=4b7fc470a6740808b41502d7431f91805e272d26
>>
>> instead.  I will clean it up and submit it tomorrow.
> This is unacceptable. It adds a new symbol version and we froze the
> ABI at the start of the month. You cannot work these fixes into 2.27
> with a new symbol version, it must wait for 2.28.

Note that the actually posted patch is completely different.

Thanks,
Florian

^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: [PATCH] Revert Intel CET changes to __jmp_buf_tag (Bug 22743)
  2018-01-25 16:36                                                                               ` Carlos O'Donell
@ 2018-01-25 16:40                                                                                 ` H.J. Lu
  2018-01-25 16:46                                                                                   ` Carlos O'Donell
  0 siblings, 1 reply; 63+ messages in thread
From: H.J. Lu @ 2018-01-25 16:40 UTC (permalink / raw)
  To: Carlos O'Donell
  Cc: Zack Weinberg, Florian Weimer, Senkevich, Andrew, Andreas Schwab,
	GNU C Library

On Thu, Jan 25, 2018 at 8:36 AM, Carlos O'Donell <carlos@redhat.com> wrote:
> On 01/25/2018 08:28 AM, H.J. Lu wrote:
>> On Thu, Jan 25, 2018 at 8:22 AM, Zack Weinberg <zackw@panix.com> wrote:
>>> On Thu, Jan 25, 2018 at 10:33 AM, H.J. Lu <hjl.tools@gmail.com> wrote:
>>>> On Thu, Jan 25, 2018 at 6:55 AM, Zack Weinberg <zackw@panix.com> wrote:
>>>>> In my opinion, the fact that you two are having this argument
>>>>> reinforces Carlos' position: the original patch should be reverted and
>>>>> we should figure out what to do in 2.28 when we're not under time
>>>>> pressure.  HJ, do you have some concrete external reason why you must
>>>>> have this new feature in 2.27?  If so, please tell us what it is.  To
>>>>> me it doesn't seem urgent.
>>>>
>>>> My question is if we are going to fix it at all.  If yes, why not 2.27.
>>>> Both approaches are opaque to users.  They can't tell the difference.
>>>
>>> My concerns are entirely based on timing: specifically, you seem to be
>>> in a rush to squeak under the 2.27 deadline.  Rushing leads to
>>> mistakes.
>>
>> The main issue for this one is testcase.  Once a testcase is found, we
>> know how to avoid the issue.
>>
>>> This seems like the sort of thing that could reasonably be backported
>>> to the release branch(es) ... *after* we have calmly, without rushing,
>>> figured out the correct fix in mainline.
>>>
>>
>> I am fine with reverting my patch only on 2.27 branch, not on master.
>
> This does not make sense. The revert on master would last for as long as
> you have to come up with a patch that works and everyone accepts and has
> consensus.

We have 2 proposals, one with a patch and one without.  How long
should it take to make a decision?

> You checked these patches in without consensus, and instead of waiting
> or pinging for review, you checked them in.
>
> For x86_64 there is no machine maintainer, it requires community consensus,

Do we need/want machine maintainers for x86-64 (i386)?

> the port is too important not to get serious community review.
>
> They changes had negative ABI consequences, and now you have several
> people interested in making sure future patches don't break ABI.

There are no arguments here.

> You have drawn attention to this work and now you have to reach consensus
> on a solution for a primary architecture which is very important to all of
> us in the downstream distributions. More time is required to make these
> patches work.
>
> I see no clear argument for why this needs to be in 2.27.

That is fine with me.

> I will be reverting the patches in the next 8 hours.

We need this on master so that we can work on CET support.

-- 
H.J.

^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: [PATCH] Revert Intel CET changes to __jmp_buf_tag (Bug 22743)
  2018-01-25 16:40                                                                                 ` H.J. Lu
@ 2018-01-25 16:46                                                                                   ` Carlos O'Donell
  2018-01-25 17:01                                                                                     ` H.J. Lu
  0 siblings, 1 reply; 63+ messages in thread
From: Carlos O'Donell @ 2018-01-25 16:46 UTC (permalink / raw)
  To: H.J. Lu
  Cc: Zack Weinberg, Florian Weimer, Senkevich, Andrew, Andreas Schwab,
	GNU C Library

On 01/25/2018 08:40 AM, H.J. Lu wrote:
> On Thu, Jan 25, 2018 at 8:36 AM, Carlos O'Donell <carlos@redhat.com> wrote:
>> On 01/25/2018 08:28 AM, H.J. Lu wrote:
>>> On Thu, Jan 25, 2018 at 8:22 AM, Zack Weinberg <zackw@panix.com> wrote:
>>>> On Thu, Jan 25, 2018 at 10:33 AM, H.J. Lu <hjl.tools@gmail.com> wrote:
>>>>> On Thu, Jan 25, 2018 at 6:55 AM, Zack Weinberg <zackw@panix.com> wrote:
>>>>>> In my opinion, the fact that you two are having this argument
>>>>>> reinforces Carlos' position: the original patch should be reverted and
>>>>>> we should figure out what to do in 2.28 when we're not under time
>>>>>> pressure.  HJ, do you have some concrete external reason why you must
>>>>>> have this new feature in 2.27?  If so, please tell us what it is.  To
>>>>>> me it doesn't seem urgent.
>>>>>
>>>>> My question is if we are going to fix it at all.  If yes, why not 2.27.
>>>>> Both approaches are opaque to users.  They can't tell the difference.
>>>>
>>>> My concerns are entirely based on timing: specifically, you seem to be
>>>> in a rush to squeak under the 2.27 deadline.  Rushing leads to
>>>> mistakes.
>>>
>>> The main issue for this one is testcase.  Once a testcase is found, we
>>> know how to avoid the issue.
>>>
>>>> This seems like the sort of thing that could reasonably be backported
>>>> to the release branch(es) ... *after* we have calmly, without rushing,
>>>> figured out the correct fix in mainline.
>>>>
>>>
>>> I am fine with reverting my patch only on 2.27 branch, not on master.
>>
>> This does not make sense. The revert on master would last for as long as
>> you have to come up with a patch that works and everyone accepts and has
>> consensus.
> 
> We have 2 proposals, one with a patch and one without.  How long
> should it take to make a decision?

However long it takes.

Until then we revert the patches.

>> You checked these patches in without consensus, and instead of waiting
>> or pinging for review, you checked them in.
>>
>> For x86_64 there is no machine maintainer, it requires community consensus,
> 
> Do we need/want machine maintainers for x86-64 (i386)?

No. We need people to follow consensus rules, ping patches, and ask for review.

Without review we are going to increase the risk of defects going in to the port.

The point of review is to lower defect rates and attain better solutions.

>> the port is too important not to get serious community review.
>>
>> They changes had negative ABI consequences, and now you have several
>> people interested in making sure future patches don't break ABI.
> 
> There are no arguments here.
> 
>> You have drawn attention to this work and now you have to reach consensus
>> on a solution for a primary architecture which is very important to all of
>> us in the downstream distributions. More time is required to make these
>> patches work.
>>
>> I see no clear argument for why this needs to be in 2.27.
> 
> That is fine with me.
> 
>> I will be reverting the patches in the next 8 hours.
> 
> We need this on master so that we can work on CET support.

No. You do not *need* anything on master, you can work on your own branches
with all of your collaborators.

Master is for work that is complete, has consensus, and is ready to be
delivered into a public release for which we will promise ABI guarantees.

-- 
Cheers,
Carlos.

^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: [PATCH] Revert Intel CET changes to __jmp_buf_tag (Bug 22743)
  2018-01-25 16:22                                                                           ` Zack Weinberg
  2018-01-25 16:28                                                                             ` H.J. Lu
@ 2018-01-25 16:47                                                                             ` Florian Weimer
  2018-01-25 16:55                                                                               ` H.J. Lu
  1 sibling, 1 reply; 63+ messages in thread
From: Florian Weimer @ 2018-01-25 16:47 UTC (permalink / raw)
  To: Zack Weinberg, H.J. Lu
  Cc: Carlos O'Donell, Senkevich, Andrew, Andreas Schwab, GNU C Library

On 01/25/2018 05:22 PM, Zack Weinberg wrote:
> This seems like the sort of thing that could reasonably be backported
> to the release branch(es) ...*after*  we have calmly, without rushing,
> figured out the correct fix in mainline.

H.J.'s approach requires that glibc 2.27 is fixed now because once 
people build with CET, binaries will have the CET markup but still 
follow the old ABI (assuming we make the ABI change subsequently).

(I don't understand why this doesn't already happen when glibc 2.26 
headers are used to build programs with CET compiler flags.)

Thanks,
Florian

^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: [PATCH] Revert Intel CET changes to __jmp_buf_tag (Bug 22743)
  2018-01-25 16:47                                                                             ` Florian Weimer
@ 2018-01-25 16:55                                                                               ` H.J. Lu
  0 siblings, 0 replies; 63+ messages in thread
From: H.J. Lu @ 2018-01-25 16:55 UTC (permalink / raw)
  To: Florian Weimer
  Cc: Zack Weinberg, Carlos O'Donell, Senkevich, Andrew,
	Andreas Schwab, GNU C Library

On Thu, Jan 25, 2018 at 8:47 AM, Florian Weimer <fweimer@redhat.com> wrote:
> On 01/25/2018 05:22 PM, Zack Weinberg wrote:
>>
>> This seems like the sort of thing that could reasonably be backported
>> to the release branch(es) ...*after*  we have calmly, without rushing,
>> figured out the correct fix in mainline.
>
>
> H.J.'s approach requires that glibc 2.27 is fixed now because once people
> build with CET, binaries will have the CET markup but still follow the old
> ABI (assuming we make the ABI change subsequently).

No, they won't.  We haven't checked in the critical patch to turn on
the CET markup yet.  You can build glibc 2.27 with GCC 8.  But you
won't get

[hjl@gnu-6 build-x86_64-linux]$ readelf -n csu/crt1.o

Displaying notes found in: .note.gnu.property
  Owner                 Data size Description
  GNU                  0x00000010 NT_GNU_PROPERTY_TYPE_0
      Properties: x86 feature: IBT, SHSTK

Displaying notes found in: .note.ABI-tag
  Owner                 Data size Description
  GNU                  0x00000010 NT_GNU_ABI_TAG (ABI version tag)
    OS: Linux, ABI: 3.2.0
[hjl@gnu-6 build-x86_64-linux]$

Use an used padding in pthread_unwind_buf to save and restore
shadow stack isn't a long term solution.   What do we do if we need
to save and restore another register in jmp buf 5 years from now?

> (I don't understand why this doesn't already happen when glibc 2.26 headers
> are used to build programs with CET compiler flags.)
>

See above.

-- 
H.J.

^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: [PATCH] Revert Intel CET changes to __jmp_buf_tag (Bug 22743)
  2018-01-25 16:46                                                                                   ` Carlos O'Donell
@ 2018-01-25 17:01                                                                                     ` H.J. Lu
  2018-01-26  7:46                                                                                       ` Carlos O'Donell
  0 siblings, 1 reply; 63+ messages in thread
From: H.J. Lu @ 2018-01-25 17:01 UTC (permalink / raw)
  To: Carlos O'Donell
  Cc: Zack Weinberg, Florian Weimer, Senkevich, Andrew, Andreas Schwab,
	GNU C Library

On Thu, Jan 25, 2018 at 8:46 AM, Carlos O'Donell <carlos@redhat.com> wrote:
> On 01/25/2018 08:40 AM, H.J. Lu wrote:
>> On Thu, Jan 25, 2018 at 8:36 AM, Carlos O'Donell <carlos@redhat.com> wrote:
>>> On 01/25/2018 08:28 AM, H.J. Lu wrote:
>>>> On Thu, Jan 25, 2018 at 8:22 AM, Zack Weinberg <zackw@panix.com> wrote:
>>>>> On Thu, Jan 25, 2018 at 10:33 AM, H.J. Lu <hjl.tools@gmail.com> wrote:
>>>>>> On Thu, Jan 25, 2018 at 6:55 AM, Zack Weinberg <zackw@panix.com> wrote:
>>>>>>> In my opinion, the fact that you two are having this argument
>>>>>>> reinforces Carlos' position: the original patch should be reverted and
>>>>>>> we should figure out what to do in 2.28 when we're not under time
>>>>>>> pressure.  HJ, do you have some concrete external reason why you must
>>>>>>> have this new feature in 2.27?  If so, please tell us what it is.  To
>>>>>>> me it doesn't seem urgent.
>>>>>>
>>>>>> My question is if we are going to fix it at all.  If yes, why not 2.27.
>>>>>> Both approaches are opaque to users.  They can't tell the difference.
>>>>>
>>>>> My concerns are entirely based on timing: specifically, you seem to be
>>>>> in a rush to squeak under the 2.27 deadline.  Rushing leads to
>>>>> mistakes.
>>>>
>>>> The main issue for this one is testcase.  Once a testcase is found, we
>>>> know how to avoid the issue.
>>>>
>>>>> This seems like the sort of thing that could reasonably be backported
>>>>> to the release branch(es) ... *after* we have calmly, without rushing,
>>>>> figured out the correct fix in mainline.
>>>>>
>>>>
>>>> I am fine with reverting my patch only on 2.27 branch, not on master.
>>>
>>> This does not make sense. The revert on master would last for as long as
>>> you have to come up with a patch that works and everyone accepts and has
>>> consensus.
>>
>> We have 2 proposals, one with a patch and one without.  How long
>> should it take to make a decision?
>
> However long it takes.
>
> Until then we revert the patches.
>

Sure.  Please revert it now.

 I will submit a patch to re-apply it + my fix after 2.27 branch
is taken.

-- 
H.J.

^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: [PATCH] Revert Intel CET changes to __jmp_buf_tag (Bug 22743)
  2018-01-25 14:56                                                                       ` Zack Weinberg
  2018-01-25 15:33                                                                         ` H.J. Lu
@ 2018-01-25 18:26                                                                         ` Joseph Myers
  1 sibling, 0 replies; 63+ messages in thread
From: Joseph Myers @ 2018-01-25 18:26 UTC (permalink / raw)
  To: Zack Weinberg
  Cc: H.J. Lu, Florian Weimer, Carlos O'Donell, Senkevich, Andrew,
	Andreas Schwab, GNU C Library

On Thu, 25 Jan 2018, Zack Weinberg wrote:

> Also, this incident demonstrates that we need better testing of our
> ABI backward compatibility guarantees.  Automation for taking all of
> the test binaries from glibc-2.x and running them against lib*.so from
> glibc-2.y (y > x), or something like that.  Probably Joseph is in the
> best position to know how hard that would be.

I'd suggest, in the 2.x build tree,

make check rtld-prefix=SOMETHING run-program-env=SOMETHING

where the SOMETHINGs are appropriately defined to use the build or install 
trees of 2.y.  There are probably reasons that doesn't work for some or 
all tests (apart from deliberate changes in glibc that required testsuite 
changes but weren't considered to require new symbol versions) - but that 
should be the basic idea of how to test binaries using a newer glibc 
version at runtime.

(We can make changes to glibc to make that sort of thing easier if it 
turns out such changes would help, but still want to be able to do it when 
x, the old version, is a glibc version without those changes.)

-- 
Joseph S. Myers
joseph@codesourcery.com

^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: [PATCH] Revert Intel CET changes to __jmp_buf_tag (Bug 22743)
  2018-01-25 12:50                                                                   ` Florian Weimer
  2018-01-25 13:00                                                                     ` H.J. Lu
@ 2018-01-25 19:21                                                                     ` H.J. Lu
  1 sibling, 0 replies; 63+ messages in thread
From: H.J. Lu @ 2018-01-25 19:21 UTC (permalink / raw)
  To: Florian Weimer
  Cc: Carlos O'Donell, Senkevich, Andrew, Andreas Schwab, GNU C Library

On Thu, Jan 25, 2018 at 4:50 AM, Florian Weimer <fweimer@redhat.com> wrote:
> On 01/25/2018 01:38 PM, H.J. Lu wrote:
>>>
>>> I still think you are over-engineering this.  The pad array has still an
>>> unused member (the last one).  Just change sigsetjmp to store the shadow
>>> pointer in that location, then the old and new setjmp will work with the
>>> current stack layout.  As far as I can tell, there are only 64 signals,
>>> so
>>> you don't even have to change the location of the signal mask.
>>
>> No, it doesn't work.  struct pthread_unwind_buf is placed on caller's
>> stack
>> and its address is passed from applications to libpthread.   If the size
>> of
>> caller's struct pthread_unwind_buf is smaller than what libpthread
>> expects,
>> libpthread will override caller's stack.
>
>
> As far as I can see, ibuf->priv.pad[3] is currently unused.  (sig)setjmp
> could save the shadow stack pointer at the right offset in jmp_buf to hit
> this place, then all these new conditionals wouldn't be necessary. Of course
> it is still a hack, but your approach is not clearer IMHO.

FWIW, this approach doesn't work with x32 which is 64-bit process with
32-bit software pointer.  Kernel may place shadow stack above 4GB.
We need to save and restore 64-bit shadow stack register for x32.

-- 
H.J.

^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: [PATCH] Revert Intel CET changes to __jmp_buf_tag (Bug 22743)
  2018-01-25 17:01                                                                                     ` H.J. Lu
@ 2018-01-26  7:46                                                                                       ` Carlos O'Donell
  2018-01-28 18:40                                                                                         ` H.J. Lu
  0 siblings, 1 reply; 63+ messages in thread
From: Carlos O'Donell @ 2018-01-26  7:46 UTC (permalink / raw)
  To: H.J. Lu
  Cc: Zack Weinberg, Florian Weimer, Senkevich, Andrew, Andreas Schwab,
	GNU C Library

On 01/25/2018 09:01 AM, H.J. Lu wrote:
> On Thu, Jan 25, 2018 at 8:46 AM, Carlos O'Donell <carlos@redhat.com> wrote:
>> On 01/25/2018 08:40 AM, H.J. Lu wrote:
>>> On Thu, Jan 25, 2018 at 8:36 AM, Carlos O'Donell <carlos@redhat.com> wrote:
>>>> On 01/25/2018 08:28 AM, H.J. Lu wrote:
>>>>> On Thu, Jan 25, 2018 at 8:22 AM, Zack Weinberg <zackw@panix.com> wrote:
>>>>>> On Thu, Jan 25, 2018 at 10:33 AM, H.J. Lu <hjl.tools@gmail.com> wrote:
>>>>>>> On Thu, Jan 25, 2018 at 6:55 AM, Zack Weinberg <zackw@panix.com> wrote:
>>>>>>>> In my opinion, the fact that you two are having this argument
>>>>>>>> reinforces Carlos' position: the original patch should be reverted and
>>>>>>>> we should figure out what to do in 2.28 when we're not under time
>>>>>>>> pressure.  HJ, do you have some concrete external reason why you must
>>>>>>>> have this new feature in 2.27?  If so, please tell us what it is.  To
>>>>>>>> me it doesn't seem urgent.
>>>>>>>
>>>>>>> My question is if we are going to fix it at all.  If yes, why not 2.27.
>>>>>>> Both approaches are opaque to users.  They can't tell the difference.
>>>>>>
>>>>>> My concerns are entirely based on timing: specifically, you seem to be
>>>>>> in a rush to squeak under the 2.27 deadline.  Rushing leads to
>>>>>> mistakes.
>>>>>
>>>>> The main issue for this one is testcase.  Once a testcase is found, we
>>>>> know how to avoid the issue.
>>>>>
>>>>>> This seems like the sort of thing that could reasonably be backported
>>>>>> to the release branch(es) ... *after* we have calmly, without rushing,
>>>>>> figured out the correct fix in mainline.
>>>>>>
>>>>>
>>>>> I am fine with reverting my patch only on 2.27 branch, not on master.
>>>>
>>>> This does not make sense. The revert on master would last for as long as
>>>> you have to come up with a patch that works and everyone accepts and has
>>>> consensus.
>>>
>>> We have 2 proposals, one with a patch and one without.  How long
>>> should it take to make a decision?
>>
>> However long it takes.
>>
>> Until then we revert the patches.
>>
> 
> Sure.  Please revert it now.
> 
>  I will submit a patch to re-apply it + my fix after 2.27 branch
> is taken.
 
I have reverted the ABI breaking changes along with the matching
change which adds feature_1.

Thank you for working with everyone on this issue. I will spend the
day tomorrow reviewing these patches.

-- 
Cheers,
Carlos.

^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: [PATCH] Revert Intel CET changes to __jmp_buf_tag (Bug 22743)
  2018-01-26  7:46                                                                                       ` Carlos O'Donell
@ 2018-01-28 18:40                                                                                         ` H.J. Lu
  0 siblings, 0 replies; 63+ messages in thread
From: H.J. Lu @ 2018-01-28 18:40 UTC (permalink / raw)
  To: Carlos O'Donell
  Cc: Zack Weinberg, Florian Weimer, Senkevich, Andrew, Andreas Schwab,
	GNU C Library

On Thu, Jan 25, 2018 at 11:45 PM, Carlos O'Donell <carlos@redhat.com> wrote:
> On 01/25/2018 09:01 AM, H.J. Lu wrote:
>> On Thu, Jan 25, 2018 at 8:46 AM, Carlos O'Donell <carlos@redhat.com> wrote:
>>> On 01/25/2018 08:40 AM, H.J. Lu wrote:
>>>> On Thu, Jan 25, 2018 at 8:36 AM, Carlos O'Donell <carlos@redhat.com> wrote:
>>>>> On 01/25/2018 08:28 AM, H.J. Lu wrote:
>>>>>> On Thu, Jan 25, 2018 at 8:22 AM, Zack Weinberg <zackw@panix.com> wrote:
>>>>>>> On Thu, Jan 25, 2018 at 10:33 AM, H.J. Lu <hjl.tools@gmail.com> wrote:
>>>>>>>> On Thu, Jan 25, 2018 at 6:55 AM, Zack Weinberg <zackw@panix.com> wrote:
>>>>>>>>> In my opinion, the fact that you two are having this argument
>>>>>>>>> reinforces Carlos' position: the original patch should be reverted and
>>>>>>>>> we should figure out what to do in 2.28 when we're not under time
>>>>>>>>> pressure.  HJ, do you have some concrete external reason why you must
>>>>>>>>> have this new feature in 2.27?  If so, please tell us what it is.  To
>>>>>>>>> me it doesn't seem urgent.
>>>>>>>>
>>>>>>>> My question is if we are going to fix it at all.  If yes, why not 2.27.
>>>>>>>> Both approaches are opaque to users.  They can't tell the difference.
>>>>>>>
>>>>>>> My concerns are entirely based on timing: specifically, you seem to be
>>>>>>> in a rush to squeak under the 2.27 deadline.  Rushing leads to
>>>>>>> mistakes.
>>>>>>
>>>>>> The main issue for this one is testcase.  Once a testcase is found, we
>>>>>> know how to avoid the issue.
>>>>>>
>>>>>>> This seems like the sort of thing that could reasonably be backported
>>>>>>> to the release branch(es) ... *after* we have calmly, without rushing,
>>>>>>> figured out the correct fix in mainline.
>>>>>>>
>>>>>>
>>>>>> I am fine with reverting my patch only on 2.27 branch, not on master.
>>>>>
>>>>> This does not make sense. The revert on master would last for as long as
>>>>> you have to come up with a patch that works and everyone accepts and has
>>>>> consensus.
>>>>
>>>> We have 2 proposals, one with a patch and one without.  How long
>>>> should it take to make a decision?
>>>
>>> However long it takes.
>>>
>>> Until then we revert the patches.
>>>
>>
>> Sure.  Please revert it now.
>>
>>  I will submit a patch to re-apply it + my fix after 2.27 branch
>> is taken.
>
> I have reverted the ABI breaking changes along with the matching
> change which adds feature_1.
>
> Thank you for working with everyone on this issue. I will spend the
> day tomorrow reviewing these patches.
>

FYI, my current patch is on hjl/pr22743/master branch at

https://github.com/hjl-tools/glibc/tree/hjl/pr22743/master

-- 
H.J.

^ permalink raw reply	[flat|nested] 63+ messages in thread

end of thread, other threads:[~2018-01-28 16:53 UTC | newest]

Thread overview: 63+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-12-07 17:41 [PATCH 1/2] Linux/x86: Update cancel_jmp_buf to match __jmp_buf_tag [BZ #22563] H.J. Lu
2017-12-07 17:58 ` Joseph Myers
2017-12-07 18:37 ` Florian Weimer
2017-12-07 18:59   ` H.J. Lu
2017-12-07 19:09     ` Florian Weimer
2017-12-07 19:12       ` H.J. Lu
2017-12-07 19:14         ` Florian Weimer
2017-12-07 19:19           ` H.J. Lu
2017-12-07 19:25             ` Florian Weimer
2017-12-07 19:35               ` H.J. Lu
2017-12-08  2:25                 ` H.J. Lu
2017-12-14 13:06                   ` H.J. Lu
2017-12-15 17:43                     ` H.J. Lu
2017-12-18 10:25                   ` Florian Weimer
2017-12-18 11:42                     ` H.J. Lu
2017-12-18 11:49                       ` Florian Weimer
2017-12-18 12:25                         ` H.J. Lu
2017-12-18 12:52                           ` Florian Weimer
2017-12-18 13:19                             ` H.J. Lu
2017-12-18 14:13                               ` H.J. Lu
2017-12-18 14:45                                 ` Andreas Schwab
2017-12-18 14:48                                   ` H.J. Lu
2017-12-18 16:29                                     ` H.J. Lu
2018-01-09 10:47                                     ` Florian Weimer
2018-01-09 12:17                                       ` H.J. Lu
2018-01-09 16:20                                         ` Senkevich, Andrew
2018-01-21 16:16                                       ` Aurelien Jarno
2018-01-21 16:27                                         ` H.J. Lu
2018-01-21 16:50                                           ` Carlos O'Donell
2018-01-22 14:44                                           ` Senkevich, Andrew
2018-01-23 19:35                                             ` Carlos O'Donell
2018-01-23 21:13                                               ` Senkevich, Andrew
2018-01-24 18:08                                                 ` H.J. Lu
2018-01-24 18:23                                                   ` Florian Weimer
2018-01-25  0:32                                                     ` Carlos O'Donell
2018-01-25  0:56                                                       ` Joseph Myers
2018-01-25  1:09                                                       ` H.J. Lu
2018-01-25  1:44                                                         ` Carlos O'Donell
2018-01-25  1:48                                                         ` Dmitry V. Levin
2018-01-25  4:53                                                           ` [PATCH] Revert Intel CET changes to __jmp_buf_tag (Bug 22743) Carlos O'Donell
2018-01-25  5:33                                                             ` H.J. Lu
2018-01-25  9:47                                                               ` Florian Weimer
2018-01-25 12:38                                                                 ` H.J. Lu
2018-01-25 12:50                                                                   ` Florian Weimer
2018-01-25 13:00                                                                     ` H.J. Lu
2018-01-25 14:56                                                                       ` Zack Weinberg
2018-01-25 15:33                                                                         ` H.J. Lu
2018-01-25 16:22                                                                           ` Zack Weinberg
2018-01-25 16:28                                                                             ` H.J. Lu
2018-01-25 16:36                                                                               ` Carlos O'Donell
2018-01-25 16:40                                                                                 ` H.J. Lu
2018-01-25 16:46                                                                                   ` Carlos O'Donell
2018-01-25 17:01                                                                                     ` H.J. Lu
2018-01-26  7:46                                                                                       ` Carlos O'Donell
2018-01-28 18:40                                                                                         ` H.J. Lu
2018-01-25 16:47                                                                             ` Florian Weimer
2018-01-25 16:55                                                                               ` H.J. Lu
2018-01-25 18:26                                                                         ` Joseph Myers
2018-01-25 19:21                                                                     ` H.J. Lu
2018-01-25 16:37                                                               ` Carlos O'Donell
2018-01-25 16:38                                                                 ` Florian Weimer
2017-12-18 17:37                                 ` [PATCH 1/2] Linux/x86: Update cancel_jmp_buf to match __jmp_buf_tag [BZ #22563] Joseph Myers
2017-12-18 21:19                                   ` H.J. Lu

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