This is the mail archive of the
mailing list for the glibc project.
Re: RFC: Shadow Stack support in glibc
- From: Florian Weimer <fweimer at redhat dot com>
- To: Yu-cheng Yu <yu-cheng dot yu at intel dot com>
- Cc: "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, 8 Jun 2017 11:46:57 +0200
- Subject: Re: RFC: Shadow Stack support in glibc
- Authentication-results: sourceware.org; auth=none
- Authentication-results: ext-mx09.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com
- Authentication-results: ext-mx09.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=fweimer at redhat dot com
- Dkim-filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 41370DC8FF
- Dmarc-filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 41370DC8FF
- References: <CAMe9rOqN7oNWWmbw_NmaP=TpBDY7jh=MNbJQNaiOR901Rs7bcw@mail.gmail.com> <firstname.lastname@example.org> <1496876422.12598.31.camel@test-lenovo>
On 06/08/2017 01:00 AM, Yu-cheng Yu wrote:
> 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
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?
> 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?
> Since shadow stack stores only return pointers, it is not affected by
> the address/size of the program stack.
See Szabolcs' question.