This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Linux/x86: Support shadow stack pointer in setjmp/longjmp
- From: Joseph Myers <joseph at codesourcery dot com>
- To: "H.J. Lu" <hjl dot tools at gmail dot com>
- Cc: Yu-cheng Yu <yu-cheng dot yu at intel dot com>, "Tsimbalist, Igor V" <igor dot v dot tsimbalist at intel dot com>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Mon, 18 Dec 2017 18:25:06 +0000
- Subject: Re: [PATCH] Linux/x86: Support shadow stack pointer in setjmp/longjmp
- Authentication-results: sourceware.org; auth=none
- References: <20171218162753.GA25026@gmail.com> <alpine.DEB.2.20.1712181741480.26421@digraph.polyomino.org.uk> <CAMe9rOr3gEyaJZ7ukNTY=MiSdWnPbmLOqduodyk3Mx8Qn9J58w@mail.gmail.com> <CAMe9rOoMeYy21NHeL=H+gz2q=KTTPQ4ZwCNX+aP_uuy5ZDinqw@mail.gmail.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