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

On 02/08/2018 03:55 AM, Florian Weimer wrote:
> * Carlos O'Donell:
> 
>> I would like to see an argument made for CET markup against versioning
>> __pthread_register_cleanup.
> 
> I don't think __pthread_register_cleanup.  It's __sigsetjmp.  We would
> have to version __sigsetjmp.  Changing the name would be ideal, but
> this will be difficult because of its returns-twice nature.

I'm looking for a solution that yields a clearly diagnosable failure
when users mix a compiler which emits CET markup and a glibc which has
the smaller sized cancellation jump buffer.

If we version __sigsetjmp, we need to decide the semantics of the old
and new version.

A naive old version would not save the shadow stack pointer to the
reclaimed space after the newer smaller internal __sigset_t, and a newer
version would save the shadow stack pointer.

This leads to sigsegv when a user mixes as above by accident, and they
will have no warning about the problem. The CET markup will be present
in all objects they have, but when run with a newer glibc it will crash
by corrupting the stack when it writes the shadow stack pointer.

My suggestion with __pthread_register_cancel et.al. (and yes we would 
have to version all the interfaces) was to basically data version the
structure, but my original idea revolved around the idea of shifting
__pad[3] up to the start of the structure and use it for versioning.

However, your idea to version __sigsetjmp has reminded me that
__saved_mask need only be non-zero to work properly and we could
store a version cookie there, which could allow us to do the following:

* Version __sigsetjmp, and store a version cookie in __saved_mask
  indicating the version of the structure.
* Have the old __sigsetjmp disable CET since it clearly indicates
  that we have the wrong sized structure regardless of CET flags.
* Adjust the unwinder to look at __saved_mask version cooke to decide
  which sized structure it is dealing with.

Is this feasible? It would give high quality diagnostics and potentially
allow us to extend the cancellation jump buffer with more data in the
future.

> I also don't have a problem with requiring -fexceptions for
> cancellation handlers with CET support.  For additional safety, we
> could change sigsetjmp to write the shadow stack pointer before the
> kernel signal mask, so that it will still be in bounds for legacy
> cancellation handler allocation.  __pthread_register_cleanup will
> overwrite it, but I don't think we ever need to restore it, so that
> shouldn't be a problem.
 
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?

-- 
Cheers,
Carlos.


  reply	other threads:[~2018-02-09  6:27 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 [this message]
2018-02-09 10:48       ` Florian Weimer
2018-02-09 11:13         ` H.J. Lu
2018-02-09 12:11           ` Florian Weimer
2018-02-09 12:34             ` H.J. Lu
2018-02-09 14:13               ` H.J. Lu
2018-02-09 14:33                 ` Florian Weimer
2018-02-09 15:24                   ` H.J. Lu
2018-02-24  5:46               ` Carlos O'Donell
2018-02-24 15:19                 ` H.J. Lu
2018-02-24 15:46                   ` Florian Weimer
2018-02-25  2:04                     ` H.J. Lu
2018-02-25  9:26                       ` Florian Weimer
2018-02-25 11:37                         ` H.J. Lu
2018-02-25 11:59                           ` Florian Weimer
2018-02-25 12:53                             ` H.J. Lu
2018-02-25 12:55                               ` H.J. Lu
2018-02-25 12:58                                 ` Florian Weimer
2018-02-25 13:23                                   ` H.J. Lu
2018-02-25 13:31                                     ` Florian Weimer
2018-02-25 13:36                                       ` H.J. Lu
2018-02-25 13:49                                         ` H.J. Lu
2018-02-25 13:49                                         ` Florian Weimer
2018-02-25 14:00                                           ` H.J. Lu
2018-02-25 14:13                                             ` Florian Weimer
2018-02-26  3:55                                               ` H.J. Lu
2018-02-28 23:23                                                 ` Carlos O'Donell
2018-03-07 11:56                                                   ` H.J. Lu
2018-03-07 17:34                                                     ` Carlos O'Donell
2018-03-07 19:47                                                       ` H.J. Lu
2018-03-07 20:14                                                         ` H.J. Lu
2018-03-07 22:06                                                           ` H.J. Lu
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=2a02aac9-6aa3-4dc6-b122-039ae85365e8@redhat.com \
    --to=carlos@redhat.com \
    --cc=fw@deneb.enyo.de \
    --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).