This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH] Linux/x86: Support shadow stack pointer in setjmp/longjmp
On Mon, Dec 18, 2017 at 12:22 PM, H.J. Lu <email@example.com> wrote:
> On Mon, Dec 18, 2017 at 10:25 AM, Joseph Myers <firstname.lastname@example.org> 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 <email@example.com> wrote:
>>> > On Mon, Dec 18, 2017 at 9:44 AM, Joseph Myers <firstname.lastname@example.org> 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
>> 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.
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.