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 Fri, Jun 9, 2017 at 6:41 AM, Szabolcs Nagy <szabolcs.nagy@arm.com> wrote:
> 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.
>
>
We can use the unused space for SSP.
--
H.J.