Re: RFC: Shadow Stack support in glibc

[Yu-cheng Yu <yu-cheng dot yu at intel dot com>]

On Thu, 2017-06-08 at 11:46 +0200, Florian Weimer wrote:
> On 06/08/2017 01:00 AM, Yu-cheng Yu wrote:
> > 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.
> 
> There are clone modes which do not duplicate the address space, and the
> caller supplies a stack allocation.  Surely this new stack needs a
> shadow stack stored somewhere, too?
> 

The shadow stack is always copied on access.

> > 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.
> 
> Interesting.  Is the allocated shadow stack visible from user space?
> How it is sized?
> 

When a task is created from exec(), the shadow stack is allocated to the
same size as the program stack.  The reasoning is the following.
(1) Physical memory is not committed until used,
(2) Shadow stack will not overflow before the program stack does,
(3) This design relieves any shadow stack management work from
applications.

For shadow_sigaltstack, it is still allocated to the same size as the
program stack for similar reasons.

Shadow stack is readable by the application.

> > pthread_attr_xxx:
> > 
> > Since shadow stack stores only return pointers, it is not affected by
> > the address/size of the program stack.
> 
> See Szabolcs' question.
> 

I will reply to his email.

Thanks,
Yu-cheng