This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: RFC: Shadow Stack support in glibc


On 08/06/17 20:46, Yu-cheng Yu wrote:
> 
> On Thu, 2017-06-08 at 09:46 +0100, Szabolcs Nagy wrote:
>>> On 08/06/17 00:00, Yu-cheng Yu wrote:
>>>
>>> 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?
>>
> 
> Please see my reply to Florian on the reasoning of sizing the shadow
> stack.  In summary, shadow stack is allocated to the same size as the
> program stack.

as far as i understand the main thread stack can grow
(up to the rlimit or until the stack hits an already
mapped page) only 128K is committed when the process
starts (on linux).

so with a large rlimit it is in principle possible to
overflow the shadow stack.

>> thread and signal stacks may be user allocated with special
>> map flags, moving return addresses to a different place
>> is observable and introduces new failure modes (shadow stack
>> allocation failure, shadow stack overflow),
>>
> 
> The shadow stack keeps only secure copies of return addresses (in
> addition to ones already on the program stack) and cannot be directly
> written by the application.  There is no requirement to correlate the
> two stacks' location.  Allocation failure is treated the same as other
> memory allocation failure.
> 

ok, i don't think this is a major issue, but

allocation failure cannot be treated the same way as before
because sigaltstack only fails with ENOMEM if the user
supplied stack is small.

as for thread creation: the allocation of the thread stack
and the allocation of the shadow stack can happen at different
calls so the failure happens elsewhere than expected.

>> 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.
>>
> 
> Shadow stack unwinding is done with the INCSSP instruction. The
> ucontext/jmpbuf structs are likely to change and being discussed in the
> thread started by H.J.
> 

makes sense

fixing setjmp/longjmp is non-trivial since jmpbuf size is abi,
it may be possible to do without saving ssp into jmpbuf though.

> Thanks,
> Yu-cheng
> 
> 


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]