This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

On Mon, Dec 18, 2017 at 12:22 PM, H.J. Lu <> wrote:
> On Mon, Dec 18, 2017 at 10:25 AM, Joseph Myers <> 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 <> wrote:
>>> > On Mon, Dec 18, 2017 at 9:44 AM, Joseph Myers <> 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:
>>> >
>>> >;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.

As I mentioned, we need room in jmp_buf to save and restore shadow stack
pointer in setjmp/longjmp.  Since only Linux/x86 jmp_buf has a space for
shadow stack pointer, this setjmp/longjmp patch is only for Linux/x86.

I am checking it in today.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]