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

["H.J. Lu" <hjl dot tools at gmail dot com>]

On Fri, Feb 9, 2018 at 4:34 AM, H.J. Lu <hjl.tools@gmail.com> wrote:
> On Fri, Feb 9, 2018 at 4:11 AM, Florian Weimer <fw@deneb.enyo.de> wrote:
>> * H. J. Lu:
>>
>>>> My proposal is still rather hackish, but so is the existing code (the
>>>
>>> A pointer to a buffer in user program is passed to libpthread.
>>> There is a jmp buf in the buffer followed by other fields.  Since
>>> the size of jmp buf is increased in glibc 2.28, we need to know the
>>> offset of other fields. Otherwise libpthread may write beyond the
>>> buffer in user program.  I don't see how symbol versioning can help
>>> us here since the INTERNAL libpthread functions don't know the
>>> layout of __pthread_unwind_buf_t of USER programs.
>>
>> I suggest *not* to increase the size of the jump buffer.
>
> Where do we save shadow stack pointer?
>
>> CET markup will not be correct for static libraries compiled against
>> 2.27 or earlier with a CET-enabled toolchain, so this is the only
>> completely safe approach.
>
> I don't believe so.  As long as there is a single input .o file which
> isn't marked
> with CET, the output static binary won't be marked with CET.  If what
> you said is true, please file a glibc bug report.
>
>

I built glibc master with gcc-8.0.1 -mcet -fcf-protection.  Some object
files do get CET marker as expected.  But static executable isn't:

[hjl@gnu-skx-1 build-x86_64-linux]$ readelf -n elf/sln.o

Displaying notes found in: .note.gnu.property
  Owner                 Data size Description
  GNU                  0x00000010 NT_GNU_PROPERTY_TYPE_0
      Properties: x86 feature: IBT, SHSTK
[hjl@gnu-skx-1 build-x86_64-linux]$ readelf -n elf/sln

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

Displaying notes found in: .note.gnu.build-id
  Owner                 Data size Description
  GNU                  0x00000014 NT_GNU_BUILD_ID (unique build ID bitstring)
    Build ID: ab9587f0ef16086b740923f72bc1a024b6185b06
[hjl@gnu-skx-1 build-x86_64-linux]$

My CET ecosystem design prevents what you worried from happening.

-- 
H.J.