RFC: Shadow Stack support in glibc

[H.J. Lu]

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.

>>>> #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.
>>
>



-- 
H.J.