This is the mail archive of the
mailing list for the glibc project.
Re: RFC: Shadow Stack support in glibc
- From: Szabolcs Nagy <szabolcs dot nagy at arm dot com>
- To: Yu-cheng Yu <yu-cheng dot yu at intel dot com>
- Cc: nd at arm dot com, Florian Weimer <fweimer at redhat 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: Fri, 09 Jun 2017 10:05:16 +0100
- Subject: Re: RFC: Shadow Stack support in glibc
- Authentication-results: sourceware.org; auth=none
- Authentication-results: intel.com; dkim=none (message not signed) header.d=none;intel.com; dmarc=none action=none header.from=arm.com;
- Nodisclaimer: True
- References: <CAMe9rOqN7oNWWmbw_NmaP=TpBDY7jh=MNbJQNaiOR901Rs7bcw@mail.gmail.com> <email@example.com> <1496876422.12598.31.camel@test-lenovo> <59390EEB.firstname.lastname@example.org> <1496951188.15627.51.camel@test-lenovo>
- Spamdiagnosticmetadata: NSPM
- Spamdiagnosticoutput: 1:99
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:
>>> 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.
fixing setjmp/longjmp is non-trivial since jmpbuf size is abi,
it may be possible to do without saving ssp into jmpbuf though.