[PATCH] Linux/x86: Support shadow stack pointer in setjmp/longjmp

H.J. Lu hjl.tools@gmail.com
Mon Dec 18 20:22:00 GMT 2017


On Mon, Dec 18, 2017 at 10:25 AM, Joseph Myers <joseph@codesourcery.com> wrote:
> On Mon, 18 Dec 2017, H.J. Lu wrote:
>
>> Resent to glibc.  Sorry if you got this email twice.
>>
>> On Mon, Dec 18, 2017 at 9:54 AM, H.J. Lu <hjl.tools@gmail.com> wrote:
>> > On Mon, Dec 18, 2017 at 9:44 AM, Joseph Myers <joseph@codesourcery.com> wrote:
>> >> On Mon, 18 Dec 2017, H.J. Lu wrote:
>> >>
>> >>>       * sysdeps/unix/sysv/linux/i386/__longjmp.S: New file.
>> >>>       * sysdeps/unix/sysv/linux/i386/bsd-_setjmp.S: Likewise.
>> >>>       * sysdeps/unix/sysv/linux/i386/bsd-setjmp.S: Likewise.
>> >>>       * sysdeps/unix/sysv/linux/i386/setjmp.S: Likewise.
>> >>>       * sysdeps/unix/sysv/linux/x86_64/__longjmp.S: Likewise.
>> >>>       * sysdeps/unix/sysv/linux/x86_64/setjmp.S: Likewise.
>> >>
>> >> Why are all these files Linux-specific?  ____longjmp_chk is Linux-specific
>> >> because it does a sysaltstack syscall, but I don't see anything
>> >> OS-specific in these files.  Why shouldn't shadow stack support be
>> >> available for all OSes on these architectures?
>> >
>> > Shadow stack support needs CET support in OS kernel.  We are updating
>> > Linux arch_prctl syscall to support CET.
>
> But none of those files you're adding above use prctl.  I'd expect exactly
> the same code you have there to be applicable to all OSes with CET
> support, even if some other parts of the CET support in glibc are
> genuinely OS-specific.  Unless there is something genuinely OS-specific in
> this code that would be inappropriate for another OS with CET support?

You need to make room in jmpbuf for shadow stack pointer, like

sysdeps/unix/sysv/linux/x86/setjmpP.h

> Under what circumstances will __SHSTK__ be defined?  If it's only with
> non-default GCC configure options or options used to build glibc, or only
> when GCC is configured for Linux target, then I'd expect such __SHSTK__
> conditionals to be OK in OS-independent __longjmp etc. implementations.

See above.

> The only case where having it in OS-independent code would be problematic
> would be if __SHSTK__ can get defined by default when building for another
> OS, and thereby introduce dependencies on pieces that are missing for
> other OSes.  And even then, __SHSTK__ could be replaced by another
> conditional for "glibc OS-specific support is present".

CET will be enabled automatically on Linux/x86 if both GCC and binutils
support CET.  When CET is enabled, __SHSTK__  is defined by GCC.

>> >> Is support for the relevant instructions available in all binutils
>> >> versions supported for building glibc?  If not, does __SHSTK__ being
>> >> defined guarantee that GCC was built with a binutils version with the
>> >> required support, or do we need additional configure checks for binutils
>> >> support?
>> >
>> > We check if binutils and GCC support CET before we enable CET:
>> >
>> > https://sourceware.org/git/?p=glibc.git;a=commit;h=d977bdb7caa1a0795687b1ea88cd24183231a37e
>
> That doesn't seem to be one of the patches you listed as a dependency of
> this one.  Does that not matter because __SHSTK__ can never be defined
> when building glibc unless that other patch is in glibc?

I submitted the setjmp patch to show how backward binary compatibility
is preserved.   Yes, setjmp is unchanged if we aren't building glibc with
CET enabled, which will be done in a separate patch.


-- 
H.J.



More information about the Libc-alpha mailing list