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