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