This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: RFC: Shadow Stack support in glibc

On 09/06/17 14:06, H.J. Lu wrote:
> On Fri, Jun 9, 2017 at 5:57 AM, Szabolcs Nagy <> wrote:
>> On 09/06/17 12:45, H.J. Lu wrote:
>>> On Fri, Jun 9, 2017 at 4:44 AM, Szabolcs Nagy <> wrote:
>>>> On 09/06/17 12:40, H.J. Lu wrote:
>>>>> On Fri, Jun 9, 2017 at 4:32 AM, Florian Weimer <> wrote:
>>>>>> On 06/09/2017 01:28 PM, H.J. Lu wrote:
>>>>>>> Yes,  99% of codes just need to recompile.  If context functions
>>>>>>> are used or jmpbuf is used independently of setjmp/longjmp,
>>>>>>> enabling is needed.
>>>>>> Would you please clarify if the size of the type jmp_buf changes in the
>>>>>> new compilation mode?
>>>>> jmp_buf size will be increased unconditionally in glibc whose <setjmp.h>
>>>>> has
>> note that there is a large unused space in jmp_buf
>> on linux because of the hurd sigset (__saved_mask member),
>> if that space can be used in target specific ways then
>> the abi complications may be possible to avoid.
> On x86, we have
> # if __WORDSIZE == 64
> typedef long int __jmp_buf[8];
> # elif defined  __x86_64__
> __extension__ typedef long long int __jmp_buf[8];
> # else
> typedef int __jmp_buf[6];
> # endif
> We need to grow it for shadow stack.

that's just the first part of the jmp_buf struct,
what matters is the size of jmp_buf which is

struct __jmp_buf_tag
    /* NOTE: The machine-dependent definitions of `__sigsetjmp'
       assume that a `jmp_buf' begins with a `__jmp_buf' and that
       `__mask_was_saved' follows it.  Do not move these members
       or add others before it.  */
    __jmp_buf __jmpbuf;		/* Calling environment.  */
    int __mask_was_saved;	/* Saved the signal mask?  */
    __sigset_t __saved_mask;	/* Saved signal mask.  */

typedef struct __jmp_buf_tag jmp_buf[1];

and only the first few bytes of __saved_mask is used on linux,
there is lot of free space there, it's just not setup for
target specific tinkering currently.

>>>>> #if shadow stack is enabled
>>>>> asm ("Turn on shadow stack in program property"):
>>>>> #endif
>>>>> The old setjmp/longjuimp only use the old jmp_buf size and the new
>>>>> setjmp/longjuimp use the new jmp_buf size.  The new setjmp/longjmp
>>>>> are used only if all input object files have shadow stack enabled in
>>>>> program property.
>>>> what happens if a process with shadow stack enabled
>>>> dlopens a lib with shadow stack disabled?
>>> My understanding is shadow stack can be disabled at any time.
>>> If we can't do that, dlopen will fail.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]