This is the mail archive of the 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 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.

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

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


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