Re: RFC: Shadow Stack support in glibc

[Szabolcs Nagy <szabolcs dot nagy at arm dot com>]

On 08/06/17 00:00, Yu-cheng Yu wrote:
> On Mon, 2017-06-05 at 23:18 -0700, Florian Weimer wrote:
>> On 06/05/2017 11:36 PM, H.J. Lu wrote:
>>> Most of glibc functions are compatible with Shadow Stack, except for
>>>
>>> 1. setjmp/longjmp need to be extended to support Shadow Stack.
>>> 2. getcontext/setcontext may be extended to support Shadow Stack.
>>> 3. makecontext/swapcontext are hard to support Shadow Stack.
>>
>> What about these?
>>
>> clone
>> sigaltstack
>> pthread_attr_setstack
>> pthread_attr_setstackaddr
>> pthread_attr_setstacksize
>>
> 
> Please comment on the following.
> 
> Thanks,
> Yu-cheng
> 
> 
> clone:
> 
> The child's shadow stack can be copied on access, similar to
> copy-on-write of a regular memory page.  A shadow stack PTE has to be
> dirty and read-only.  When a task is cloned, the kernel makes shadow
> stack PTEs clean until they are accessed again.  At that time, a copy is
> made.
> 
> sigaltstack:
> 
> When the kernel gets the sigaltstack syscall, it allocates a
> shadow_sigaltstack and records the pointer in the task header (similar
> to the existing sigaltstack pointer).  If there is another sigaltstack
> syscall, the kernel frees the previous shadow_sigaltstack; else, the
> shadow_sigaltstack is freed upon task exit.
> 
> pthread_attr_xxx:
> 
> Since shadow stack stores only return pointers, it is not affected by
> the address/size of the program stack.

why is it not affected by the size of the program stack?
how is the size of the shadow stack determined?

thread and signal stacks may be user allocated with special
mmap flags, moving return addresses to a different place
is observable and introduces new failure modes (shadow stack
allocation failure, shadow stack overflow), it is not clear
how an unwinder may access the shadow stack nor how the
ucontext/jmpbuf structs may store the new ssp register without
breaking abi.