Re: [PATCH 0/2] nptl: Update struct pthread_unwind_buf

[Carlos O'Donell <carlos at redhat dot com>]

On 02/08/2018 05:27 AM, H.J. Lu wrote:
> On Thu, Feb 8, 2018 at 1:25 AM, Carlos O'Donell <carlos@redhat.com> wrote:
>> Again, I would like to see an argument made for CET markup against versioning
>> __pthread_register_cleanup.
> 
> Symbol versioning works well when only opaque data pointers are used.
> A pointer of struct pthread_unwind_buf is passed to libpthread from user
> programs.  Within libpthread, we need to know the exact layout of struct
> pthread_unwind_buf.  It is next to impossible to use symbol versioning here.

My worry is about incorrectly marked up objects which use the wrong unwind
buffer size resulting in difficult to diagnose crashes.

The exact issue would be users using a gcc and binutils which marks up binaries
with CET notes, but glibc headers which are not CET enabled.

This will happen when we ship Developer Toolset with a gcc and binutils that
has CET support, but the system glibc is still < 2.28. Then users will take
these binaries and try to run them on systems with glibc >= 2.28 because we
allow this backwards compatibility, and this will segfault because we are
turning on CET, but mixing different sized unwind buffers.

Please tell me if you think my worries are unfounded, or of sufficiently
low risk that they will not be a problem, or that we can somehow say that
what was done was unsupported e.g. saying that Developer Toolset used with
Intel CET flags to build anything on any system with glibc < 2.28 generates
unsupported binaries.

My suggestion in the other email is that we briefly investigate what it would
take version the data in the unwind buffer such that we *can* handle different
sized objects properly, and enable us to potentially grow the unwind data
we have in the future.

To reiterate from my other email:
* 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.

The third bullet point is effectively what you are *already* doing
with the CET flags, but using the flags in a coarse way to decide
which of 2 sizes of unwind buffers we are using. This has the problems that
I outline above which is that it is error prone. While the symbol version
mechanism will always tell us exactly which sized object was used when
the TU was compiled.

-- 
Cheers,
Carlos.