On Thu, Jan 25, 2018 at 1:47 AM, Florian Weimer wrote: > On 01/25/2018 06:33 AM, H.J. Lu wrote: > >> Please don't revert my patch. Please try this patch: >> >> >> https://sourceware.org/git/?p=glibc.git;a=commit;h=4b7fc470a6740808b41502d7431f91805e272d26 >> >> instead. I will clean it up and submit it tomorrow. > > > I don't see how adding a symbol version to pthread_create helps to solve the > general case. Callers of pthread_register_cancel and pthread_create are > often compiled at different times. Not everyone does a mass rebuild each > time they switch to a new glibc version. True. We just need to use the older struct pthread_unwind_buf when shadow stack is disabled. > I still think you are over-engineering this. The pad array has still an > unused member (the last one). Just change sigsetjmp to store the shadow > pointer in that location, then the old and new setjmp will work with the > current stack layout. As far as I can tell, there are only 64 signals, so > you don't even have to change the location of the signal mask. No, it doesn't work. struct pthread_unwind_buf is placed on caller's stack and its address is passed from applications to libpthread. If the size of caller's struct pthread_unwind_buf is smaller than what libpthread expects, libpthread will override caller's stack. > Furthermore, nothing in the toolchain prevents people from compiling That is not true. From CET spec: https://github.com/hjl-tools/x86-psABI/wiki/x86-64-psABI-cet.pdf On a SHSTK capable processor, the following steps should be taken: 1. When loading an executable without interpreter, enable and lock SHSTK if GNU_PROPERTY_X86_FEATURE_1_SHSTK is set on the executable. 2. When loading an executable with an interpreter, enable SHSTK if GNU_PROPERTY_X86_FEATURE_1_SHSTK is set on the interpreter. The interpreter should disable SHSTK if GNU_PROPERTY_X86_FEATURE_1_SHSTK isn’t set or any shared objects loaded via the DT_NEEDED tag, otherwise lock SHSTK. 3. After SHSTK is enabled, it is an error to load a shared object without GNU_PROPERTY_X86_FEATURE_1_SHSTK. > CET-marked binaries with older glibc headers, so you can't use CET markup to > determine the size of the stack allocation anyway. > Yes, we can. We enable shadow stack at run-time only if program and all used shared objects, including dlopened ones, are shadow stack enabled, which means that they must be compiled with GCC 8 or above and glibc 2.27 or above. Since we need to save and restore shadow stack only if shadow stack is enabled, we can safely assume that caller is compiled with smaller struct pthread_unwind_buf on stack if shadow stack isn't enabled at run-time. For callers with larger struct pthread_unwind_buf, but shadow stack isn't enabled, we just have some unused space on caller's stack. Here is the patch to do that, Andrew, please work with Debian to verify that fixes the crash. BTW, my patch is on hjl/pr22743/master branch in glibc git repo. Thanks. -- H.J.