This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
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 <szabolcs.nagy@arm.com> wrote:
>> On 09/06/17 12:45, H.J. Lu wrote:
>>> On Fri, Jun 9, 2017 at 4:44 AM, Szabolcs Nagy <szabolcs.nagy@arm.com> wrote:
>>>> On 09/06/17 12:40, H.J. Lu wrote:
>>>>> On Fri, Jun 9, 2017 at 4:32 AM, Florian Weimer <fweimer@redhat.com> 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.
>>>
>>
>
>
>