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

[Joseph Myers <joseph@codesourcery.com>]

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?

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.  
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".

> >> 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?

-- 
Joseph S. Myers
joseph@codesourcery.com