This is the mail archive of the
mailing list for the glibc project.
Re: RFC: Shadow Stack support in glibc
- From: Yu-cheng Yu <yu-cheng dot yu at intel dot com>
- To: Szabolcs Nagy <szabolcs dot nagy at arm dot com>
- Cc: Florian Weimer <fweimer at redhat dot com>, nd at arm dot com, "H.J. Lu" <hjl dot tools at gmail dot com>, GNU C Library <libc-alpha at sourceware dot org>, Igor Tsimbalist <tigor dot tools at gmail dot com>, "Shanbhogue, Vedvyas" <vedvyas dot shanbhogue at intel dot com>
- Date: Thu, 08 Jun 2017 12:46:28 -0700
- Subject: Re: RFC: Shadow Stack support in glibc
- Authentication-results: sourceware.org; auth=none
- References: <CAMe9rOqN7oNWWmbw_NmaP=TpBDY7jh=MNbJQNaiOR901Rs7bcw@mail.gmail.com> <firstname.lastname@example.org> <1496876422.12598.31.camel@test-lenovo> <59390EEB.email@example.com>
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
> 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.