unofficial mirror of libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Florian Weimer <fw@deneb.enyo.de>
To: Carlos O'Donell <carlos@redhat.com>
Cc: "H.J. Lu" <hjl.tools@gmail.com>,  libc-alpha@sourceware.org
Subject: Re: [PATCH 0/2] nptl: Update struct pthread_unwind_buf
Date: Fri, 09 Feb 2018 11:48:30 +0100	[thread overview]
Message-ID: <87d11emoap.fsf@mid.deneb.enyo.de> (raw)
In-Reply-To: <2a02aac9-6aa3-4dc6-b122-039ae85365e8@redhat.com> (Carlos O'Donell's message of "Thu, 8 Feb 2018 22:29:32 -0800")

* Carlos O'Donell:

> In the truncated sigjmp_buf used by pthread cancellation we have only 
> void * which is not large enough on x32, where you need a 64-bit
> shadow stack pointer. It would work on every other machine though.
> HJ has mentioned this problem already IIRC.
>
> Why would __pthread_register_cancel overwrite it?

__pthread_unwind_buf_t is defined as:

typedef struct
{
  struct
  {
    __jmp_buf __cancel_jmp_buf;
    int __mask_was_saved;
  } __cancel_jmp_buf[1];
  void *__pad[4];
} __pthread_unwind_buf_t __attribute__ ((__aligned__));

pthread_cleanup_push does this:

# 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 {

__pthread_register_cancel overwrites __cancel_buf.__pad.  If
__sigsetjmp were to write to that memory area, it would not matter, as
long as we skip restoring the shadow stack pointer during unwinding
(which we do not need to do because we never return along the regular
execution path recorded on the shadow stack).

In short, the only thing need to ensure is that the over-write from
__sigsetjmp stays within __cancel_buf.  Then we are good, without
changing the stack layout for cancellation.

My proposal is still rather hackish, but so is the existing code (the
truncated jump buffer), and HJ's approach of storing the shadow stack
pointer in the signal save area of the non-truncated jump buffer.  But
I think we can make it work.


  reply	other threads:[~2018-02-09 10:47 UTC|newest]

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

Reply instructions:

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

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

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

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

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

  git send-email \
    --in-reply-to=87d11emoap.fsf@mid.deneb.enyo.de \
    --to=fw@deneb.enyo.de \
    --cc=carlos@redhat.com \
    --cc=hjl.tools@gmail.com \
    --cc=libc-alpha@sourceware.org \
    /path/to/YOUR_REPLY

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

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