[11/17] x86/cet: Sync with Linux kernel 6.6 shadow stack interface
Checks
| Context |
Check |
Description |
| redhat-pt-bot/TryBot-apply_patch |
success
|
Patch applied to master at the time it was sent
|
| linaro-tcwg-bot/tcwg_glibc_build--master-aarch64 |
fail
|
Patch failed to apply
|
| linaro-tcwg-bot/tcwg_glibc_build--master-arm |
fail
|
Patch failed to apply
|
Commit Message
Sync with Linux kernel 6.6 shadow stack interface. Since only x86-64 is
supported, i386 shadow stack codes are unchanged and CET shouldn't be
enabled for i386.
1. When the shadow stack base in TCB is unset, the default shadow stack
is in use. Use the current shadow stack pointer as the marker for the
default shadow stack.
2. Allocate shadow stack with the map_shadow_stack syscall.
3. Rename arch_prctl CET commands to ARCH_SHSTK_XXX.
4. Rewrite the CET control functions with the current kernel shadow stack
interface.
Since CET is no longer enabled by kernel, a separate patch will enable
shadow stack during startup.
---
sysdeps/unix/sysv/linux/x86/Makefile | 1 +
.../sysv/linux/x86/allocate-shadow-stack.c | 54 +++++++++++++++++++
.../sysv/linux/x86/allocate-shadow-stack.h | 27 ++++++++++
sysdeps/unix/sysv/linux/x86/bits/mman.h | 5 ++
sysdeps/unix/sysv/linux/x86/cpu-features.c | 13 +++--
sysdeps/unix/sysv/linux/x86/dl-cet.h | 16 ++++--
.../unix/sysv/linux/x86/include/asm/prctl.h | 37 ++++++-------
.../sysv/linux/x86/tst-cet-setcontext-1.c | 17 +++---
.../unix/sysv/linux/x86_64/__start_context.S | 38 +++----------
sysdeps/unix/sysv/linux/x86_64/getcontext.S | 30 ++---------
sysdeps/unix/sysv/linux/x86_64/makecontext.c | 29 +++++-----
sysdeps/unix/sysv/linux/x86_64/swapcontext.S | 22 ++------
sysdeps/x86/cpu-features.c | 15 ++++--
sysdeps/x86/dl-cet.c | 2 +-
sysdeps/x86_64/nptl/tls.h | 2 +-
15 files changed, 176 insertions(+), 132 deletions(-)
create mode 100644 sysdeps/unix/sysv/linux/x86/allocate-shadow-stack.c
create mode 100644 sysdeps/unix/sysv/linux/x86/allocate-shadow-stack.h
Comments
The 12/06/2023 09:20, H.J. Lu wrote:
> Sync with Linux kernel 6.6 shadow stack interface. Since only x86-64 is
> supported, i386 shadow stack codes are unchanged and CET shouldn't be
> enabled for i386.
>
> 1. When the shadow stack base in TCB is unset, the default shadow stack
> is in use. Use the current shadow stack pointer as the marker for the
> default shadow stack.
what is the role of ssp_base in the tcb?
> 2. Allocate shadow stack with the map_shadow_stack syscall.
> 3. Rename arch_prctl CET commands to ARCH_SHSTK_XXX.
> 4. Rewrite the CET control functions with the current kernel shadow stack
> interface.
>
> Since CET is no longer enabled by kernel, a separate patch will enable
> shadow stack during startup.
...
> +/* NB: This can be treated as a syscall by caller. */
> +
> +#ifndef __x86_64__
> +__attribute__ ((regparm (2)))
> +#endif
> +long int
> +__allocate_shadow_stack (size_t stack_size,
> + shadow_stack_size_t *child_stack)
> +{
> +#ifdef __NR_map_shadow_stack
> + size_t shadow_stack_size
> + = stack_size >> STACK_SIZE_TO_SHADOW_STACK_SIZE_SHIFT;
> + /* Align shadow stack to 8 bytes. */
> + shadow_stack_size = ALIGN_UP (shadow_stack_size, 8);
since sigaltstack shares shadow stack with the current context
in the thread, this should include the shadow stack requirement
for signal handlers too. otherwise a user can use makecontext
to fill up a shadow stack such that a stack overflow signal
handler cannot run (presumably a crash handler should be able
to handle crashes in all situations).
i think a fixed fixed size is enough to cover for reasonable
signal handler (e.g. ~20 stack frames).
> + void *shadow_stack = (void *)INLINE_SYSCALL_CALL
> + (map_shadow_stack, NULL, shadow_stack_size, SHADOW_STACK_SET_TOKEN);
> + /* Report the map_shadow_stack error. */
> + if (shadow_stack == MAP_FAILED)
> + return -errno;
> +
> + /* Save the shadow stack base and size on child stack. */
> + child_stack[0] = (uintptr_t) shadow_stack;
> + child_stack[1] = shadow_stack_size;
> +
> + return 0;
> +#else
> + return -ENOSYS;
> +#endif
> +}
...
> --- a/sysdeps/unix/sysv/linux/x86_64/makecontext.c
> +++ b/sysdeps/unix/sysv/linux/x86_64/makecontext.c
> @@ -24,6 +24,8 @@
> # include <pthread.h>
> # include <libc-pointer-arith.h>
> # include <sys/prctl.h>
> +# include <sys/mman.h>
> +# include <allocate-shadow-stack.h>
> #endif
>
> #include "ucontext_i.h"
> @@ -88,23 +90,24 @@ __makecontext (ucontext_t *ucp, void (*func) (void), int argc, ...)
> if ((feature_1 & X86_FEATURE_1_SHSTK) != 0)
> {
> /* Shadow stack is enabled. We need to allocate a new shadow
> - stack. */
> - unsigned long ssp_size = (((uintptr_t) sp
> - - (uintptr_t) ucp->uc_stack.ss_sp)
> - >> STACK_SIZE_TO_SHADOW_STACK_SIZE_SHIFT);
> - /* Align shadow stack to 8 bytes. */
> - ssp_size = ALIGN_UP (ssp_size, 8);
> -
> - ucp->__ssp[1] = ssp_size;
> - ucp->__ssp[2] = ssp_size;
> -
> - /* Call __push___start_context to allocate a new shadow stack,
> - push __start_context onto the new stack as well as the new
> - shadow stack. NB: After __push___start_context returns,
> + stack. NB:
> ucp->__ssp[0]: The new shadow stack pointer.
> ucp->__ssp[1]: The base address of the new shadow stack.
> ucp->__ssp[2]: The size of the new shadow stack.
> */
> + long int ret
> + = __allocate_shadow_stack (((uintptr_t) sp
> + - (uintptr_t) ucp->uc_stack.ss_sp),
> + &ucp->__ssp[1]);
this allocation in glibc does not seem to be freed in glibc.
so normal makecontext use will leak the shadow stack.
(e.g. this is true even if the makecontext function returns
and thus the shadow stack lifetime ends).
> + if (ret != 0)
> + {
> + /* FIXME: What should we do? */
> + abort ();
makecontext cannot report errors, so we can make this an
error in setcontext/swapcontext (not sure if that's
better in practice, but it is more compatible with the
posix api).
> + }
> +
> + ucp->__ssp[0] = ucp->__ssp[1] + ucp->__ssp[2] - 8;
> + /* Call __push___start_context to push __start_context onto the new
> + stack as well as the new shadow stack. */
> __push___start_context (ucp);
...
> --- a/sysdeps/x86_64/nptl/tls.h
> +++ b/sysdeps/x86_64/nptl/tls.h
> @@ -60,7 +60,7 @@ typedef struct
> void *__private_tm[4];
> /* GCC split stack support. */
> void *__private_ss;
> - /* The lowest address of shadow stack, */
> + /* The marker for the current shadow stack. */
> unsigned long long int ssp_base;
is this abi between libc/unwinder or compiler or something else?
On Mon, Dec 11, 2023 at 3:34 AM Szabolcs Nagy <szabolcs.nagy@arm.com> wrote:
>
> The 12/06/2023 09:20, H.J. Lu wrote:
> > Sync with Linux kernel 6.6 shadow stack interface. Since only x86-64 is
> > supported, i386 shadow stack codes are unchanged and CET shouldn't be
> > enabled for i386.
> >
> > 1. When the shadow stack base in TCB is unset, the default shadow stack
> > is in use. Use the current shadow stack pointer as the marker for the
> > default shadow stack.
>
> what is the role of ssp_base in the tcb?
It is used to identify if the current stack is the same as the target
shadow stack when switching ucontexts. If yes, INCSSP will
be used to unwind shadow stack. Otherwise, shadow stack
restore token will be used.
> > 2. Allocate shadow stack with the map_shadow_stack syscall.
> > 3. Rename arch_prctl CET commands to ARCH_SHSTK_XXX.
> > 4. Rewrite the CET control functions with the current kernel shadow stack
> > interface.
> >
> > Since CET is no longer enabled by kernel, a separate patch will enable
> > shadow stack during startup.
> ...
> > +/* NB: This can be treated as a syscall by caller. */
> > +
> > +#ifndef __x86_64__
> > +__attribute__ ((regparm (2)))
> > +#endif
> > +long int
> > +__allocate_shadow_stack (size_t stack_size,
> > + shadow_stack_size_t *child_stack)
> > +{
> > +#ifdef __NR_map_shadow_stack
> > + size_t shadow_stack_size
> > + = stack_size >> STACK_SIZE_TO_SHADOW_STACK_SIZE_SHIFT;
> > + /* Align shadow stack to 8 bytes. */
> > + shadow_stack_size = ALIGN_UP (shadow_stack_size, 8);
>
> since sigaltstack shares shadow stack with the current context
> in the thread, this should include the shadow stack requirement
> for signal handlers too. otherwise a user can use makecontext
> to fill up a shadow stack such that a stack overflow signal
> handler cannot run (presumably a crash handler should be able
> to handle crashes in all situations).
>
> i think a fixed fixed size is enough to cover for reasonable
> signal handler (e.g. ~20 stack frames).
It sounds reasonable.
>
> > + void *shadow_stack = (void *)INLINE_SYSCALL_CALL
> > + (map_shadow_stack, NULL, shadow_stack_size, SHADOW_STACK_SET_TOKEN);
> > + /* Report the map_shadow_stack error. */
> > + if (shadow_stack == MAP_FAILED)
> > + return -errno;
> > +
> > + /* Save the shadow stack base and size on child stack. */
> > + child_stack[0] = (uintptr_t) shadow_stack;
> > + child_stack[1] = shadow_stack_size;
> > +
> > + return 0;
> > +#else
> > + return -ENOSYS;
> > +#endif
> > +}
> ...
> > --- a/sysdeps/unix/sysv/linux/x86_64/makecontext.c
> > +++ b/sysdeps/unix/sysv/linux/x86_64/makecontext.c
> > @@ -24,6 +24,8 @@
> > # include <pthread.h>
> > # include <libc-pointer-arith.h>
> > # include <sys/prctl.h>
> > +# include <sys/mman.h>
> > +# include <allocate-shadow-stack.h>
> > #endif
> >
> > #include "ucontext_i.h"
> > @@ -88,23 +90,24 @@ __makecontext (ucontext_t *ucp, void (*func) (void), int argc, ...)
> > if ((feature_1 & X86_FEATURE_1_SHSTK) != 0)
> > {
> > /* Shadow stack is enabled. We need to allocate a new shadow
> > - stack. */
> > - unsigned long ssp_size = (((uintptr_t) sp
> > - - (uintptr_t) ucp->uc_stack.ss_sp)
> > - >> STACK_SIZE_TO_SHADOW_STACK_SIZE_SHIFT);
> > - /* Align shadow stack to 8 bytes. */
> > - ssp_size = ALIGN_UP (ssp_size, 8);
> > -
> > - ucp->__ssp[1] = ssp_size;
> > - ucp->__ssp[2] = ssp_size;
> > -
> > - /* Call __push___start_context to allocate a new shadow stack,
> > - push __start_context onto the new stack as well as the new
> > - shadow stack. NB: After __push___start_context returns,
> > + stack. NB:
> > ucp->__ssp[0]: The new shadow stack pointer.
> > ucp->__ssp[1]: The base address of the new shadow stack.
> > ucp->__ssp[2]: The size of the new shadow stack.
> > */
> > + long int ret
> > + = __allocate_shadow_stack (((uintptr_t) sp
> > + - (uintptr_t) ucp->uc_stack.ss_sp),
> > + &ucp->__ssp[1]);
>
> this allocation in glibc does not seem to be freed in glibc.
>
> so normal makecontext use will leak the shadow stack.
>
> (e.g. this is true even if the makecontext function returns
> and thus the shadow stack lifetime ends).
Correct. Since there is no function to explicitly release ucontext,
there is no place to release shadow stack and shadow stack will
be leaked.
> > + if (ret != 0)
> > + {
> > + /* FIXME: What should we do? */
> > + abort ();
>
> makecontext cannot report errors, so we can make this an
> error in setcontext/swapcontext (not sure if that's
> better in practice, but it is more compatible with the
> posix api).
>
> > + }
> > +
> > + ucp->__ssp[0] = ucp->__ssp[1] + ucp->__ssp[2] - 8;
> > + /* Call __push___start_context to push __start_context onto the new
> > + stack as well as the new shadow stack. */
> > __push___start_context (ucp);
> ...
> > --- a/sysdeps/x86_64/nptl/tls.h
> > +++ b/sysdeps/x86_64/nptl/tls.h
> > @@ -60,7 +60,7 @@ typedef struct
> > void *__private_tm[4];
> > /* GCC split stack support. */
> > void *__private_ss;
> > - /* The lowest address of shadow stack, */
> > + /* The marker for the current shadow stack. */
> > unsigned long long int ssp_base;
>
> is this abi between libc/unwinder or compiler or something else?
This is used by ucontext functions internally in glibc.
Thanks.
The 12/11/2023 08:44, H.J. Lu wrote:
> On Mon, Dec 11, 2023 at 3:34 AM Szabolcs Nagy <szabolcs.nagy@arm.com> wrote:
> > The 12/06/2023 09:20, H.J. Lu wrote:
> > > Sync with Linux kernel 6.6 shadow stack interface. Since only x86-64 is
> > > supported, i386 shadow stack codes are unchanged and CET shouldn't be
> > > enabled for i386.
> > >
> > > 1. When the shadow stack base in TCB is unset, the default shadow stack
> > > is in use. Use the current shadow stack pointer as the marker for the
> > > default shadow stack.
> >
> > what is the role of ssp_base in the tcb?
>
> It is used to identify if the current stack is the same as the target
> shadow stack when switching ucontexts. If yes, INCSSP will
> be used to unwind shadow stack. Otherwise, shadow stack
> restore token will be used.
i would like to support stack switching in longjmp too
(for aarch64 gcs) not just in setcontext/swapcontext.
if you assume that the target shadow stack always ends in a
restore token when a jump is switching stack, then scanning
the shadow stack until the token or current ssp is found works.
(tcb ssp_base is not needed.)
the linear scanning affects longjmp performance but it seems
the overhead is amortized by the creation of the stack frames.
if you don't want this in longjmp, then code using it for task
scheduling across worker threads have to be patched to use
*context (means signal mask saving syscall overhead so some
projects may not like this) or marked as non-shadow-stack compat.
On Tue, Dec 12, 2023 at 10:03 AM Szabolcs Nagy <szabolcs.nagy@arm.com> wrote:
>
> The 12/11/2023 08:44, H.J. Lu wrote:
> > On Mon, Dec 11, 2023 at 3:34 AM Szabolcs Nagy <szabolcs.nagy@arm.com> wrote:
> > > The 12/06/2023 09:20, H.J. Lu wrote:
> > > > Sync with Linux kernel 6.6 shadow stack interface. Since only x86-64 is
> > > > supported, i386 shadow stack codes are unchanged and CET shouldn't be
> > > > enabled for i386.
> > > >
> > > > 1. When the shadow stack base in TCB is unset, the default shadow stack
> > > > is in use. Use the current shadow stack pointer as the marker for the
> > > > default shadow stack.
> > >
> > > what is the role of ssp_base in the tcb?
> >
> > It is used to identify if the current stack is the same as the target
> > shadow stack when switching ucontexts. If yes, INCSSP will
> > be used to unwind shadow stack. Otherwise, shadow stack
> > restore token will be used.
>
> i would like to support stack switching in longjmp too
> (for aarch64 gcs) not just in setcontext/swapcontext.
>
> if you assume that the target shadow stack always ends in a
> restore token when a jump is switching stack, then scanning
> the shadow stack until the token or current ssp is found works.
> (tcb ssp_base is not needed.)
We can't put a restore token on shadow stack for setjmp since
longjmp is optional, not required. If longjmp isn't called, there
will be an extra restore token on shadow stack. One way to
switch arbitrary shadow stack is to allow write shadow stack,
which will reduce security.
> the linear scanning affects longjmp performance but it seems
> the overhead is amortized by the creation of the stack frames.
>
> if you don't want this in longjmp, then code using it for task
> scheduling across worker threads have to be patched to use
> *context (means signal mask saving syscall overhead so some
> projects may not like this) or marked as non-shadow-stack compat.
>
The 12/12/2023 10:39, H.J. Lu wrote:
> On Tue, Dec 12, 2023 at 10:03 AM Szabolcs Nagy <szabolcs.nagy@arm.com> wrote:
> >
> > The 12/11/2023 08:44, H.J. Lu wrote:
> > > On Mon, Dec 11, 2023 at 3:34 AM Szabolcs Nagy <szabolcs.nagy@arm.com> wrote:
> > > > The 12/06/2023 09:20, H.J. Lu wrote:
> > > > > Sync with Linux kernel 6.6 shadow stack interface. Since only x86-64 is
> > > > > supported, i386 shadow stack codes are unchanged and CET shouldn't be
> > > > > enabled for i386.
> > > > >
> > > > > 1. When the shadow stack base in TCB is unset, the default shadow stack
> > > > > is in use. Use the current shadow stack pointer as the marker for the
> > > > > default shadow stack.
> > > >
> > > > what is the role of ssp_base in the tcb?
> > >
> > > It is used to identify if the current stack is the same as the target
> > > shadow stack when switching ucontexts. If yes, INCSSP will
> > > be used to unwind shadow stack. Otherwise, shadow stack
> > > restore token will be used.
> >
> > i would like to support stack switching in longjmp too
> > (for aarch64 gcs) not just in setcontext/swapcontext.
> >
> > if you assume that the target shadow stack always ends in a
> > restore token when a jump is switching stack, then scanning
> > the shadow stack until the token or current ssp is found works.
> > (tcb ssp_base is not needed.)
>
> We can't put a restore token on shadow stack for setjmp since
> longjmp is optional, not required. If longjmp isn't called, there
> will be an extra restore token on shadow stack. One way to
> switch arbitrary shadow stack is to allow write shadow stack,
> which will reduce security.
>
setjmp never switches stacks, so it must not place a token.
only stack switching operations need to place tokens.
longjmp cannot target arbitrary setjmp that happened on another
stack: if that stack is still in use by another thread then the
two threads clobber each other's stack. it can only work if that
stack is switched away from and at that point a token was placed.
we can make this the abi: you can only longjmp to a stack which
is switched away from such that a token is placed on it.
in terms of conformance i belive we only need the incssp case,
anything else is qoi extension, but such extensions are used in
practice, e.g. for longjmp between stacks created by makecontext.
> > the linear scanning affects longjmp performance but it seems
> > the overhead is amortized by the creation of the stack frames.
> >
> > if you don't want this in longjmp, then code using it for task
> > scheduling across worker threads have to be patched to use
> > *context (means signal mask saving syscall overhead so some
> > projects may not like this) or marked as non-shadow-stack compat.
> >
>
>
> --
> H.J.
On Wed, Dec 13, 2023 at 2:49 AM Szabolcs Nagy <szabolcs.nagy@arm.com> wrote:
>
> The 12/12/2023 10:39, H.J. Lu wrote:
> > On Tue, Dec 12, 2023 at 10:03 AM Szabolcs Nagy <szabolcs.nagy@arm.com> wrote:
> > >
> > > The 12/11/2023 08:44, H.J. Lu wrote:
> > > > On Mon, Dec 11, 2023 at 3:34 AM Szabolcs Nagy <szabolcs.nagy@arm.com> wrote:
> > > > > The 12/06/2023 09:20, H.J. Lu wrote:
> > > > > > Sync with Linux kernel 6.6 shadow stack interface. Since only x86-64 is
> > > > > > supported, i386 shadow stack codes are unchanged and CET shouldn't be
> > > > > > enabled for i386.
> > > > > >
> > > > > > 1. When the shadow stack base in TCB is unset, the default shadow stack
> > > > > > is in use. Use the current shadow stack pointer as the marker for the
> > > > > > default shadow stack.
> > > > >
> > > > > what is the role of ssp_base in the tcb?
> > > >
> > > > It is used to identify if the current stack is the same as the target
> > > > shadow stack when switching ucontexts. If yes, INCSSP will
> > > > be used to unwind shadow stack. Otherwise, shadow stack
> > > > restore token will be used.
> > >
> > > i would like to support stack switching in longjmp too
> > > (for aarch64 gcs) not just in setcontext/swapcontext.
> > >
> > > if you assume that the target shadow stack always ends in a
> > > restore token when a jump is switching stack, then scanning
> > > the shadow stack until the token or current ssp is found works.
> > > (tcb ssp_base is not needed.)
> >
> > We can't put a restore token on shadow stack for setjmp since
> > longjmp is optional, not required. If longjmp isn't called, there
> > will be an extra restore token on shadow stack. One way to
> > switch arbitrary shadow stack is to allow write shadow stack,
> > which will reduce security.
> >
>
> setjmp never switches stacks, so it must not place a token.
>
> only stack switching operations need to place tokens.
>
> longjmp cannot target arbitrary setjmp that happened on another
> stack: if that stack is still in use by another thread then the
> two threads clobber each other's stack. it can only work if that
> stack is switched away from and at that point a token was placed.
> we can make this the abi: you can only longjmp to a stack which
> is switched away from such that a token is placed on it.
The restore token is put on shadow stack by setcontext and
swapcontext. When longjmp is called, it doesn't know if there
is a token or not. If longjmp keeps searching for the token and
doesn't find it, it will run out of shadow stack. Rick, can we
assume that the shadow stack entries are 0, if they aren't in
use?
> in terms of conformance i belive we only need the incssp case,
> anything else is qoi extension, but such extensions are used in
> practice, e.g. for longjmp between stacks created by makecontext.
>
> > > the linear scanning affects longjmp performance but it seems
> > > the overhead is amortized by the creation of the stack frames.
> > >
> > > if you don't want this in longjmp, then code using it for task
> > > scheduling across worker threads have to be patched to use
> > > *context (means signal mask saving syscall overhead so some
> > > projects may not like this) or marked as non-shadow-stack compat.
> > >
> >
> >
> > --
> > H.J.
On Wed, 2023-12-13 at 14:45 -0800, H.J. Lu wrote:
> > longjmp cannot target arbitrary setjmp that happened on another
> > stack: if that stack is still in use by another thread then the
> > two threads clobber each other's stack. it can only work if that
> > stack is switched away from and at that point a token was placed.
> > we can make this the abi: you can only longjmp to a stack which
> > is switched away from such that a token is placed on it.
>
> The restore token is put on shadow stack by setcontext and
> swapcontext. When longjmp is called, it doesn't know if there
> is a token or not. If longjmp keeps searching for the token and
> doesn't find it, it will run out of shadow stack. Rick, can we
> assume that the shadow stack entries are 0, if they aren't in
> use?
Not sure what you mean by entries not in use. You mean the restore
token? The shadow stack entries are not zeroed as they are popped by
RET.
longjmp() doesn't return an error code, so is a crash actually ok here?
I'm remembering another issue that came up when this idea was discussed
before. Apps might not call SAVEPREVSSP after they RSTORSSP. You can
just just swap away and not leave a token. So setjmp() cannot be
guaranteed to work with custom stack switching code. It has to be one
of the rules, at least for x86.
I need to go dig through the mails, but I thought there were some more
limitations (that could also be rules) that we ran into.
On Wed, Dec 13, 2023 at 3:54 PM Edgecombe, Rick P
<rick.p.edgecombe@intel.com> wrote:
>
> On Wed, 2023-12-13 at 14:45 -0800, H.J. Lu wrote:
> > > longjmp cannot target arbitrary setjmp that happened on another
> > > stack: if that stack is still in use by another thread then the
> > > two threads clobber each other's stack. it can only work if that
> > > stack is switched away from and at that point a token was placed.
> > > we can make this the abi: you can only longjmp to a stack which
> > > is switched away from such that a token is placed on it.
> >
> > The restore token is put on shadow stack by setcontext and
> > swapcontext. When longjmp is called, it doesn't know if there
> > is a token or not. If longjmp keeps searching for the token and
> > doesn't find it, it will run out of shadow stack. Rick, can we
> > assume that the shadow stack entries are 0, if they aren't in
> > use?
>
> Not sure what you mean by entries not in use. You mean the restore
> token? The shadow stack entries are not zeroed as they are popped by
> RET.
>
longjmp needs to know when to stop searching the token since there
won't be one if setcontext and swapcontext aren't called on the shadow
stack where setjmp is called. Will checking for zero shadow stack entry
value work here? It is OK if the value isn't zeroed by RET as long as
zero value can be checked to avoid going beyond the shadow stack boundary.
> longjmp() doesn't return an error code, so is a crash actually ok here?
>
>
> I'm remembering another issue that came up when this idea was discussed
> before. Apps might not call SAVEPREVSSP after they RSTORSSP. You can
> just just swap away and not leave a token. So setjmp() cannot be
> guaranteed to work with custom stack switching code. It has to be one
> of the rules, at least for x86.
>
> I need to go dig through the mails, but I thought there were some more
> limitations (that could also be rules) that we ran into.
On Wed, Dec 13, 2023 at 4:20 PM H.J. Lu <hjl.tools@gmail.com> wrote:
>
> On Wed, Dec 13, 2023 at 3:54 PM Edgecombe, Rick P
> <rick.p.edgecombe@intel.com> wrote:
> >
> > On Wed, 2023-12-13 at 14:45 -0800, H.J. Lu wrote:
> > > > longjmp cannot target arbitrary setjmp that happened on another
> > > > stack: if that stack is still in use by another thread then the
> > > > two threads clobber each other's stack. it can only work if that
> > > > stack is switched away from and at that point a token was placed.
> > > > we can make this the abi: you can only longjmp to a stack which
> > > > is switched away from such that a token is placed on it.
> > >
> > > The restore token is put on shadow stack by setcontext and
> > > swapcontext. When longjmp is called, it doesn't know if there
> > > is a token or not. If longjmp keeps searching for the token and
> > > doesn't find it, it will run out of shadow stack. Rick, can we
> > > assume that the shadow stack entries are 0, if they aren't in
> > > use?
> >
> > Not sure what you mean by entries not in use. You mean the restore
> > token? The shadow stack entries are not zeroed as they are popped by
> > RET.
> >
>
> longjmp needs to know when to stop searching the token since there
> won't be one if setcontext and swapcontext aren't called on the shadow
> stack where setjmp is called. Will checking for zero shadow stack entry
> value work here? It is OK if the value isn't zeroed by RET as long as
> zero value can be checked to avoid going beyond the shadow stack boundary.
Here are 2 patches:
1. Add a test for longjmp from a user context.
2. Check the restore token in longjmp.
Do they make sense?
> > longjmp() doesn't return an error code, so is a crash actually ok here?
> >
> >
> > I'm remembering another issue that came up when this idea was discussed
> > before. Apps might not call SAVEPREVSSP after they RSTORSSP. You can
> > just just swap away and not leave a token. So setjmp() cannot be
> > guaranteed to work with custom stack switching code. It has to be one
> > of the rules, at least for x86.
> >
> > I need to go dig through the mails, but I thought there were some more
> > limitations (that could also be rules) that we ran into.
>
>
>
> --
> H.J.
The 12/13/2023 18:21, H.J. Lu wrote:
> On Wed, Dec 13, 2023 at 4:20 PM H.J. Lu <hjl.tools@gmail.com> wrote:
> >
> > On Wed, Dec 13, 2023 at 3:54 PM Edgecombe, Rick P
> > <rick.p.edgecombe@intel.com> wrote:
> > >
> > > On Wed, 2023-12-13 at 14:45 -0800, H.J. Lu wrote:
> > > > > longjmp cannot target arbitrary setjmp that happened on another
> > > > > stack: if that stack is still in use by another thread then the
> > > > > two threads clobber each other's stack. it can only work if that
> > > > > stack is switched away from and at that point a token was placed.
> > > > > we can make this the abi: you can only longjmp to a stack which
> > > > > is switched away from such that a token is placed on it.
> > > >
> > > > The restore token is put on shadow stack by setcontext and
> > > > swapcontext. When longjmp is called, it doesn't know if there
> > > > is a token or not. If longjmp keeps searching for the token and
> > > > doesn't find it, it will run out of shadow stack. Rick, can we
> > > > assume that the shadow stack entries are 0, if they aren't in
> > > > use?
> > >
> > > Not sure what you mean by entries not in use. You mean the restore
> > > token? The shadow stack entries are not zeroed as they are popped by
> > > RET.
> > >
> >
> > longjmp needs to know when to stop searching the token since there
> > won't be one if setcontext and swapcontext aren't called on the shadow
> > stack where setjmp is called. Will checking for zero shadow stack entry
> > value work here? It is OK if the value isn't zeroed by RET as long as
> > zero value can be checked to avoid going beyond the shadow stack boundary.
>
> Here are 2 patches:
>
> 1. Add a test for longjmp from a user context.
> 2. Check the restore token in longjmp.
>
> Do they make sense?
>
> > > longjmp() doesn't return an error code, so is a crash actually ok here?
> > >
> > >
> > > I'm remembering another issue that came up when this idea was discussed
> > > before. Apps might not call SAVEPREVSSP after they RSTORSSP. You can
> > > just just swap away and not leave a token. So setjmp() cannot be
> > > guaranteed to work with custom stack switching code. It has to be one
> > > of the rules, at least for x86.
> > >
> > > I need to go dig through the mails, but I thought there were some more
> > > limitations (that could also be rules) that we ran into.
so the rule can be that if a user wants a stack to be resumable
then a restore token must be placed on that stack when switching
away from it, if the token is not there then longjmp is ub and
may crash. (so no need to check for 0, such longjmp is a user error)
custom shadow stack switch code has to take this into account.
> From ce1045ecfe9ff40fdc8c7c8cf766175229d475b7 Mon Sep 17 00:00:00 2001
> From: "H.J. Lu" <hjl.tools@gmail.com>
> Date: Wed, 13 Dec 2023 17:50:47 -0800
> Subject: [PATCH 2/2] x86-64/cet: Check the restore token in longjmp
>
> setcontext and swapcontext put a restore token on the old shadow stack
> so that they switch to a different shadow stack when switching user
> contexts. When longjmp from a user context, the target shadow stack
> can be different from the current shadow stack and INCSSP can't be
> used to restore the shadow stack pointer to the target shadow stack.
> Update longjmp to search for a restore token. If found, use the token
> to restore the shadow stack pointer before using INCSSP to pop the
> shadow stack. Stop the token search if the shadow stack entry value
> is zero.
>
> NB: The token search will segfault if there is no restore token and all
> shadow stack entries are non-zero.
this is reasonable except for a comment below.
> ---
> sysdeps/x86_64/__longjmp.S | 25 ++++++++++++++++++++++++-
> 1 file changed, 24 insertions(+), 1 deletion(-)
>
> diff --git a/sysdeps/x86_64/__longjmp.S b/sysdeps/x86_64/__longjmp.S
> index 9ac075e0a8..0d37e91af5 100644
> --- a/sysdeps/x86_64/__longjmp.S
> +++ b/sysdeps/x86_64/__longjmp.S
> @@ -64,8 +64,31 @@ ENTRY(__longjmp)
> /* Get the current ssp. */
> rdsspq %rax
> /* And compare it with the saved ssp value. */
> - subq SHADOW_STACK_POINTER_OFFSET(%rdi), %rax
> + movq SHADOW_STACK_POINTER_OFFSET(%rdi), %rcx
> + subq %rcx, %rax
> je L(skip_ssp)
> +
> +L(find_restore_token_loop):
> + /* Look for a restore token. */
> + movq -8(%rcx), %rbx
> + andq $-8, %rbx
> + /* Stop if the shadow stack entry value is zero. */
> + jz L(no_shadow_stack_token)
> + cmpq %rcx, %rbx
> + /* Find the restore token. */
> + je L(restore_shadow_stack)
> +
> + /* Try the next slot. */
> + subq $8, %rcx
> + jmp L(find_restore_token_loop)
> +
> +L(restore_shadow_stack):
> + /* Restore the target shadow stack. */
> + rstorssp -8(%rcx)
i think a restore token is needed on the old shadow stack,
so if there was a setjmp on that stack one can resume to it.
(essentially longjmp behaves like setcontext when it is used
for stack switching: it leaves behind a resumable stack)
> + rdsspq %rax
> + subq SHADOW_STACK_POINTER_OFFSET(%rdi), %rax
> +
> +L(no_shadow_stack_token):
> /* Count the number of frames to adjust and adjust it
> with incssp instruction. The instruction can adjust
> the ssp by [0..255] value only thus use a loop if
> --
> 2.43.0
>
> From bee9c6265f6eb1754c82464755af265e2587c2c9 Mon Sep 17 00:00:00 2001
> From: "H.J. Lu" <hjl.tools@gmail.com>
> Date: Wed, 13 Dec 2023 11:13:16 -0800
> Subject: [PATCH 1/2] Add a test for longjmp from user context
>
> Verify that longjmp works correctly after setcontext is called to switch
> to a user context.
> ---
> stdlib/Makefile | 1 +
> stdlib/tst-setcontext10.c | 87 +++++++++++++++++++++++++++++++++++++++
> 2 files changed, 88 insertions(+)
> create mode 100644 stdlib/tst-setcontext10.c
>
> diff --git a/stdlib/Makefile b/stdlib/Makefile
> index 0b154e57c5..8c6249aab4 100644
> --- a/stdlib/Makefile
> +++ b/stdlib/Makefile
> @@ -234,6 +234,7 @@ tests := \
> tst-setcontext7 \
> tst-setcontext8 \
> tst-setcontext9 \
> + tst-setcontext10 \
> tst-strfmon_l \
> tst-strfrom \
> tst-strfrom-locale \
> diff --git a/stdlib/tst-setcontext10.c b/stdlib/tst-setcontext10.c
> new file mode 100644
> index 0000000000..a311d9f783
> --- /dev/null
> +++ b/stdlib/tst-setcontext10.c
> @@ -0,0 +1,87 @@
> +/* Check longjmp from user context.
> + Copyright (C) 2023 Free Software Foundation, Inc.
> + This file is part of the GNU C Library.
> +
> + The GNU C Library is free software; you can redistribute it and/or
> + modify it under the terms of the GNU Lesser General Public
> + License as published by the Free Software Foundation; either
> + version 2.1 of the License, or (at your option) any later version.
> +
> + The GNU C Library is distributed in the hope that it will be useful,
> + but WITHOUT ANY WARRANTY; without even the implied warranty of
> + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
> + Lesser General Public License for more details.
> +
> + You should have received a copy of the GNU Lesser General Public
> + License along with the GNU C Library; if not, see
> + <https://www.gnu.org/licenses/>. */
> +
> +#include <stdio.h>
> +#include <stdlib.h>
> +#include <setjmp.h>
> +#include <ucontext.h>
> +#include <unistd.h>
> +
> +static jmp_buf jmpbuf;
> +static ucontext_t ctx;
> +
> +static void f2 (void);
> +
> +static void
> +__attribute__ ((noinline, noclone))
> +f1 (void)
> +{
> + printf ("start f1\n");
> + f2 ();
> +}
> +
> +static void
> +__attribute__ ((noinline, noclone))
> +f2 (void)
> +{
> + printf ("start f2\n");
> + if (setcontext (&ctx) != 0)
> + {
> + printf ("%s: setcontext: %m\n", __FUNCTION__);
> + exit (EXIT_FAILURE);
> + }
> +}
> +
> +static void
> +f3 (void)
> +{
> + printf ("start f3\n");
> + longjmp (jmpbuf, 1);
> +}
i would do a setjmp here before longjmp and jump back to that
point from the main stack to see if longjmp left behind a
resumable stack.
> +
> +static int
> +__attribute__ ((noinline, noclone))
> +do_test_1 (void)
> +{
> + char st1[32768];
> +
> + if (setjmp (jmpbuf) != 0)
> + return 0;
> +
> + puts ("making contexts");
> + if (getcontext (&ctx) != 0)
> + {
> + printf ("%s: getcontext: %m\n", __FUNCTION__);
> + exit (EXIT_FAILURE);
> + }
> + ctx.uc_stack.ss_sp = st1;
> + ctx.uc_stack.ss_size = sizeof st1;
> + ctx.uc_link = NULL;
> + makecontext (&ctx, (void (*) (void)) f3, 0);
> + f1 ();
> + puts ("FAIL: returned from f1 ()");
> + exit (EXIT_FAILURE);
> +}
> +
> +static int
> +do_test (void)
> +{
> + return do_test_1 ();
> +}
> +
> +#include <support/test-driver.c>
> --
> 2.43.0
>
On Thu, Dec 14, 2023 at 9:13 AM szabolcs.nagy@arm.com
<szabolcs.nagy@arm.com> wrote:
>
> The 12/13/2023 18:21, H.J. Lu wrote:
> > On Wed, Dec 13, 2023 at 4:20 PM H.J. Lu <hjl.tools@gmail.com> wrote:
> > >
> > > On Wed, Dec 13, 2023 at 3:54 PM Edgecombe, Rick P
> > > <rick.p.edgecombe@intel.com> wrote:
> > > >
> > > > On Wed, 2023-12-13 at 14:45 -0800, H.J. Lu wrote:
> > > > > > longjmp cannot target arbitrary setjmp that happened on another
> > > > > > stack: if that stack is still in use by another thread then the
> > > > > > two threads clobber each other's stack. it can only work if that
> > > > > > stack is switched away from and at that point a token was placed.
> > > > > > we can make this the abi: you can only longjmp to a stack which
> > > > > > is switched away from such that a token is placed on it.
> > > > >
> > > > > The restore token is put on shadow stack by setcontext and
> > > > > swapcontext. When longjmp is called, it doesn't know if there
> > > > > is a token or not. If longjmp keeps searching for the token and
> > > > > doesn't find it, it will run out of shadow stack. Rick, can we
> > > > > assume that the shadow stack entries are 0, if they aren't in
> > > > > use?
> > > >
> > > > Not sure what you mean by entries not in use. You mean the restore
> > > > token? The shadow stack entries are not zeroed as they are popped by
> > > > RET.
> > > >
> > >
> > > longjmp needs to know when to stop searching the token since there
> > > won't be one if setcontext and swapcontext aren't called on the shadow
> > > stack where setjmp is called. Will checking for zero shadow stack entry
> > > value work here? It is OK if the value isn't zeroed by RET as long as
> > > zero value can be checked to avoid going beyond the shadow stack boundary.
> >
> > Here are 2 patches:
> >
> > 1. Add a test for longjmp from a user context.
> > 2. Check the restore token in longjmp.
> >
> > Do they make sense?
> >
> > > > longjmp() doesn't return an error code, so is a crash actually ok here?
> > > >
> > > >
> > > > I'm remembering another issue that came up when this idea was discussed
> > > > before. Apps might not call SAVEPREVSSP after they RSTORSSP. You can
> > > > just just swap away and not leave a token. So setjmp() cannot be
> > > > guaranteed to work with custom stack switching code. It has to be one
> > > > of the rules, at least for x86.
> > > >
> > > > I need to go dig through the mails, but I thought there were some more
> > > > limitations (that could also be rules) that we ran into.
>
> so the rule can be that if a user wants a stack to be resumable
> then a restore token must be placed on that stack when switching
That is fine.
> away from it, if the token is not there then longjmp is ub and
> may crash. (so no need to check for 0, such longjmp is a user error)
We need to check for 0. Otherwise, all current setjmp tests segfault
since there is no restore token on the target shadow stack.
> custom shadow stack switch code has to take this into account.
>
>
> > From ce1045ecfe9ff40fdc8c7c8cf766175229d475b7 Mon Sep 17 00:00:00 2001
> > From: "H.J. Lu" <hjl.tools@gmail.com>
> > Date: Wed, 13 Dec 2023 17:50:47 -0800
> > Subject: [PATCH 2/2] x86-64/cet: Check the restore token in longjmp
> >
> > setcontext and swapcontext put a restore token on the old shadow stack
> > so that they switch to a different shadow stack when switching user
> > contexts. When longjmp from a user context, the target shadow stack
> > can be different from the current shadow stack and INCSSP can't be
> > used to restore the shadow stack pointer to the target shadow stack.
> > Update longjmp to search for a restore token. If found, use the token
> > to restore the shadow stack pointer before using INCSSP to pop the
> > shadow stack. Stop the token search if the shadow stack entry value
> > is zero.
> >
> > NB: The token search will segfault if there is no restore token and all
> > shadow stack entries are non-zero.
>
> this is reasonable except for a comment below.
>
> > ---
> > sysdeps/x86_64/__longjmp.S | 25 ++++++++++++++++++++++++-
> > 1 file changed, 24 insertions(+), 1 deletion(-)
> >
> > diff --git a/sysdeps/x86_64/__longjmp.S b/sysdeps/x86_64/__longjmp.S
> > index 9ac075e0a8..0d37e91af5 100644
> > --- a/sysdeps/x86_64/__longjmp.S
> > +++ b/sysdeps/x86_64/__longjmp.S
> > @@ -64,8 +64,31 @@ ENTRY(__longjmp)
> > /* Get the current ssp. */
> > rdsspq %rax
> > /* And compare it with the saved ssp value. */
> > - subq SHADOW_STACK_POINTER_OFFSET(%rdi), %rax
> > + movq SHADOW_STACK_POINTER_OFFSET(%rdi), %rcx
> > + subq %rcx, %rax
> > je L(skip_ssp)
> > +
> > +L(find_restore_token_loop):
> > + /* Look for a restore token. */
> > + movq -8(%rcx), %rbx
> > + andq $-8, %rbx
> > + /* Stop if the shadow stack entry value is zero. */
> > + jz L(no_shadow_stack_token)
> > + cmpq %rcx, %rbx
> > + /* Find the restore token. */
> > + je L(restore_shadow_stack)
> > +
> > + /* Try the next slot. */
> > + subq $8, %rcx
> > + jmp L(find_restore_token_loop)
> > +
> > +L(restore_shadow_stack):
> > + /* Restore the target shadow stack. */
> > + rstorssp -8(%rcx)
>
> i think a restore token is needed on the old shadow stack,
> so if there was a setjmp on that stack one can resume to it.
Who will put a restore token on shadow stack when user context
isn't used? If kernel does it, CALL will override the restore token
when the end of shadow stack is reached.
> (essentially longjmp behaves like setcontext when it is used
> for stack switching: it leaves behind a resumable stack)
>
> > + rdsspq %rax
> > + subq SHADOW_STACK_POINTER_OFFSET(%rdi), %rax
> > +
> > +L(no_shadow_stack_token):
> > /* Count the number of frames to adjust and adjust it
> > with incssp instruction. The instruction can adjust
> > the ssp by [0..255] value only thus use a loop if
> > --
> > 2.43.0
> >
>
> > From bee9c6265f6eb1754c82464755af265e2587c2c9 Mon Sep 17 00:00:00 2001
> > From: "H.J. Lu" <hjl.tools@gmail.com>
> > Date: Wed, 13 Dec 2023 11:13:16 -0800
> > Subject: [PATCH 1/2] Add a test for longjmp from user context
> >
> > Verify that longjmp works correctly after setcontext is called to switch
> > to a user context.
> > ---
> > stdlib/Makefile | 1 +
> > stdlib/tst-setcontext10.c | 87 +++++++++++++++++++++++++++++++++++++++
> > 2 files changed, 88 insertions(+)
> > create mode 100644 stdlib/tst-setcontext10.c
> >
> > diff --git a/stdlib/Makefile b/stdlib/Makefile
> > index 0b154e57c5..8c6249aab4 100644
> > --- a/stdlib/Makefile
> > +++ b/stdlib/Makefile
> > @@ -234,6 +234,7 @@ tests := \
> > tst-setcontext7 \
> > tst-setcontext8 \
> > tst-setcontext9 \
> > + tst-setcontext10 \
> > tst-strfmon_l \
> > tst-strfrom \
> > tst-strfrom-locale \
> > diff --git a/stdlib/tst-setcontext10.c b/stdlib/tst-setcontext10.c
> > new file mode 100644
> > index 0000000000..a311d9f783
> > --- /dev/null
> > +++ b/stdlib/tst-setcontext10.c
> > @@ -0,0 +1,87 @@
> > +/* Check longjmp from user context.
> > + Copyright (C) 2023 Free Software Foundation, Inc.
> > + This file is part of the GNU C Library.
> > +
> > + The GNU C Library is free software; you can redistribute it and/or
> > + modify it under the terms of the GNU Lesser General Public
> > + License as published by the Free Software Foundation; either
> > + version 2.1 of the License, or (at your option) any later version.
> > +
> > + The GNU C Library is distributed in the hope that it will be useful,
> > + but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
> > + Lesser General Public License for more details.
> > +
> > + You should have received a copy of the GNU Lesser General Public
> > + License along with the GNU C Library; if not, see
> > + <https://www.gnu.org/licenses/>. */
> > +
> > +#include <stdio.h>
> > +#include <stdlib.h>
> > +#include <setjmp.h>
> > +#include <ucontext.h>
> > +#include <unistd.h>
> > +
> > +static jmp_buf jmpbuf;
> > +static ucontext_t ctx;
> > +
> > +static void f2 (void);
> > +
> > +static void
> > +__attribute__ ((noinline, noclone))
> > +f1 (void)
> > +{
> > + printf ("start f1\n");
> > + f2 ();
> > +}
> > +
> > +static void
> > +__attribute__ ((noinline, noclone))
> > +f2 (void)
> > +{
> > + printf ("start f2\n");
> > + if (setcontext (&ctx) != 0)
> > + {
> > + printf ("%s: setcontext: %m\n", __FUNCTION__);
> > + exit (EXIT_FAILURE);
> > + }
> > +}
> > +
> > +static void
> > +f3 (void)
> > +{
> > + printf ("start f3\n");
> > + longjmp (jmpbuf, 1);
> > +}
>
> i would do a setjmp here before longjmp and jump back to that
> point from the main stack to see if longjmp left behind a
> resumable stack.
This is a different test. I will add it.
> > +
> > +static int
> > +__attribute__ ((noinline, noclone))
> > +do_test_1 (void)
> > +{
> > + char st1[32768];
> > +
> > + if (setjmp (jmpbuf) != 0)
> > + return 0;
> > +
> > + puts ("making contexts");
> > + if (getcontext (&ctx) != 0)
> > + {
> > + printf ("%s: getcontext: %m\n", __FUNCTION__);
> > + exit (EXIT_FAILURE);
> > + }
> > + ctx.uc_stack.ss_sp = st1;
> > + ctx.uc_stack.ss_size = sizeof st1;
> > + ctx.uc_link = NULL;
> > + makecontext (&ctx, (void (*) (void)) f3, 0);
> > + f1 ();
> > + puts ("FAIL: returned from f1 ()");
> > + exit (EXIT_FAILURE);
> > +}
> > +
> > +static int
> > +do_test (void)
> > +{
> > + return do_test_1 ();
> > +}
> > +
> > +#include <support/test-driver.c>
> > --
> > 2.43.0
> >
>
Thanks.
+x86 folks
Thread:
https://public-inbox.org/libc-alpha/CAMe9rOoU2Ows-zd=hx1qpf-vMA7q=yoNYnty2NgY5T5zn58bWw@mail.gmail.com/
On Thu, 2023-12-14 at 09:40 -0800, H.J. Lu wrote:
> > so the rule can be that if a user wants a stack to be resumable
> > then a restore token must be placed on that stack when switching
>
> That is fine.
>
> > away from it, if the token is not there then longjmp is ub and
> > may crash. (so no need to check for 0, such longjmp is a user
> > error)
>
> We need to check for 0. Otherwise, all current setjmp tests segfault
> since there is no restore token on the target shadow stack.
A couple thoughts on this.
I guess the problem is: how does longjmp() know if the target ssp
(setjmp() point) is already on the same stack as the current ssp?
Should it INCSSP back to it, or search for a token the other direction?
To determine this, the proposed algorithm is to search up the shadow
stack from the target ssp for a token or zero. If none are found,
incssp back from the current ssp to get the the target ssp.
One problem is, a zero is not guaranteed to be there because the whole
shadow stack could have been used in the past. In the case of no zero
frame to be found, valid longjmp()s on the same shadow stack could
fail. So this fixes some longjmp() between stacks scenarios, but at the
cost of making longjmp() on the same stack unreliable.
You could do the opposite order: search backwards (INCSSP loop) first,
until you get to the begging of the shadow stack stack, then try to
search for the token. But then you needs to be able to find the start
of the stack. A start token would be a bit more unusual to get
overwritten. An app would have to INCSSP back to the start of the
stack, and then overwrite it with CALLs.
Another idea would be to have a RO, non-shadow stack page at the start
of the stack instead of the unmapped guard page. It would serve the
same purpose as the guard page, but could have a non-overwritable zero
value to search for. Since this would be the "zero page", it actually
wouldn't use any extra memory over an unmapped area, since all zero
guard pages could use the same physical memory. This might be doable
today from userspace, with MAP_FIXED, but it could get tricky to clean
it up and need kernel assistance.
But this doesn't solve the problem of longjmp() from an alt shadow
stack. If glibc ends up using WRSS for that, then this all seems overly
complex. I also wonder how much all this searching of the entire stack
will hurt the performance of apps using longjmp() for speed.
What about the rule being: No longjmp() between shadow stacks, unless
you enable WRSS. Glibc could detect WRSS and take advantage whenever
present. We would have to figure out how to do a WRSS elf bit in a way
that makes sense. So most apps don't need to enable WRSS, but the few
ones that longjmp() between stacks can just flip a switch and
get support with similar performance characteristics.
And then a secure-longjmp() mode could be a lockdown mode added later
if there is demand. I don't know, what do you guys think?
On Thu, Dec 14, 2023 at 3:01 PM Edgecombe, Rick P
<rick.p.edgecombe@intel.com> wrote:
>
> +x86 folks
>
> Thread:
> https://public-inbox.org/libc-alpha/CAMe9rOoU2Ows-zd=hx1qpf-vMA7q=yoNYnty2NgY5T5zn58bWw@mail.gmail.com/
>
>
> On Thu, 2023-12-14 at 09:40 -0800, H.J. Lu wrote:
> > > so the rule can be that if a user wants a stack to be resumable
> > > then a restore token must be placed on that stack when switching
> >
> > That is fine.
> >
> > > away from it, if the token is not there then longjmp is ub and
> > > may crash. (so no need to check for 0, such longjmp is a user
> > > error)
> >
> > We need to check for 0. Otherwise, all current setjmp tests segfault
> > since there is no restore token on the target shadow stack.
>
> A couple thoughts on this.
>
> I guess the problem is: how does longjmp() know if the target ssp
> (setjmp() point) is already on the same stack as the current ssp?
> Should it INCSSP back to it, or search for a token the other direction?
> To determine this, the proposed algorithm is to search up the shadow
> stack from the target ssp for a token or zero. If none are found,
> incssp back from the current ssp to get the the target ssp.
>
> One problem is, a zero is not guaranteed to be there because the whole
> shadow stack could have been used in the past. In the case of no zero
> frame to be found, valid longjmp()s on the same shadow stack could
> fail. So this fixes some longjmp() between stacks scenarios, but at the
> cost of making longjmp() on the same stack unreliable.
When the whole shadow stack has been used, one more CALL
will also overflow shadow stack. This is the same as longjmp segfault.
> You could do the opposite order: search backwards (INCSSP loop) first,
> until you get to the begging of the shadow stack stack, then try to
> search for the token. But then you needs to be able to find the start
> of the stack. A start token would be a bit more unusual to get
> overwritten. An app would have to INCSSP back to the start of the
> stack, and then overwrite it with CALLs.
>
> Another idea would be to have a RO, non-shadow stack page at the start
> of the stack instead of the unmapped guard page. It would serve the
> same purpose as the guard page, but could have a non-overwritable zero
> value to search for. Since this would be the "zero page", it actually
> wouldn't use any extra memory over an unmapped area, since all zero
> guard pages could use the same physical memory. This might be doable
> today from userspace, with MAP_FIXED, but it could get tricky to clean
> it up and need kernel assistance.
>
> But this doesn't solve the problem of longjmp() from an alt shadow
> stack. If glibc ends up using WRSS for that, then this all seems overly
> complex. I also wonder how much all this searching of the entire stack
> will hurt the performance of apps using longjmp() for speed.
>
> What about the rule being: No longjmp() between shadow stacks, unless
> you enable WRSS. Glibc could detect WRSS and take advantage whenever
> present. We would have to figure out how to do a WRSS elf bit in a way
> that makes sense. So most apps don't need to enable WRSS, but the few
> ones that longjmp() between stacks can just flip a switch and
> get support with similar performance characteristics.
>
> And then a secure-longjmp() mode could be a lockdown mode added later
> if there is demand. I don't know, what do you guys think?
>
On Thu, 2023-12-14 at 15:47 -0800, H.J. Lu wrote:
> > A couple thoughts on this.
> >
> > I guess the problem is: how does longjmp() know if the target ssp
> > (setjmp() point) is already on the same stack as the current ssp?
> > Should it INCSSP back to it, or search for a token the other
> > direction?
> > To determine this, the proposed algorithm is to search up the
> > shadow
> > stack from the target ssp for a token or zero. If none are found,
> > incssp back from the current ssp to get the the target ssp.
> >
> > One problem is, a zero is not guaranteed to be there because the
> > whole
> > shadow stack could have been used in the past. In the case of no
> > zero
> > frame to be found, valid longjmp()s on the same shadow stack could
> > fail. So this fixes some longjmp() between stacks scenarios, but at
> > the
> > cost of making longjmp() on the same stack unreliable.
>
> When the whole shadow stack has been used, one more CALL
> will also overflow shadow stack. This is the same as longjmp
> segfault.
Just chatted with HJ. We discussed and agreed this method is not
reliable. My preference would be to not have a solution that works
halfway. Either the pattern should be not supported (the current
situation), or work deterministically (WRSS, guard gap manipulation
ideas, etc).
The 12/14/2023 09:40, H.J. Lu wrote:
> On Thu, Dec 14, 2023 at 9:13 AM szabolcs.nagy@arm.com
> > so the rule can be that if a user wants a stack to be resumable
> > then a restore token must be placed on that stack when switching
>
> That is fine.
>
> > away from it, if the token is not there then longjmp is ub and
> > may crash. (so no need to check for 0, such longjmp is a user error)
>
> We need to check for 0. Otherwise, all current setjmp tests segfault
> since there is no restore token on the target shadow stack.
i don't understand this claim.
any longjmp target ssp is either
- on the same stack: you can check targetssp == ssp
- or different stack: you can check *targetssp == restore token
as you scan the target ssp.
the second case relies on the described stack switch abi rule.
> > > +L(restore_shadow_stack):
> > > + /* Restore the target shadow stack. */
> > > + rstorssp -8(%rcx)
> >
> > i think a restore token is needed on the old shadow stack,
> > so if there was a setjmp on that stack one can resume to it.
>
> Who will put a restore token on shadow stack when user context
> isn't used? If kernel does it, CALL will override the restore token
> when the end of shadow stack is reached.
anybody who switches away from the stack has to place a token,
this is simply the abi.
if no token is placed that means all the old stack frames are
not available for switching. (e.g. if the kernel does not place
a token on syscall entry, then longjmp is not allowed to jump
to the stack of another thread that happens to be in a syscall,
which is totally reasonable and it's a good thing that we prevent
such broken longjmp usage imo)
you could design a different abi (e.g. one that relies on wrss),
but i don't see the problem with the abi i'm describing.
On Fri, Dec 15, 2023 at 1:23 AM szabolcs.nagy@arm.com
<szabolcs.nagy@arm.com> wrote:
>
> The 12/14/2023 09:40, H.J. Lu wrote:
> > On Thu, Dec 14, 2023 at 9:13 AM szabolcs.nagy@arm.com
> > > so the rule can be that if a user wants a stack to be resumable
> > > then a restore token must be placed on that stack when switching
> >
> > That is fine.
> >
> > > away from it, if the token is not there then longjmp is ub and
> > > may crash. (so no need to check for 0, such longjmp is a user error)
> >
> > We need to check for 0. Otherwise, all current setjmp tests segfault
> > since there is no restore token on the target shadow stack.
>
> i don't understand this claim.
>
> any longjmp target ssp is either
> - on the same stack: you can check targetssp == ssp
> - or different stack: you can check *targetssp == restore token
> as you scan the target ssp.
longjmp doesn't know if the target SSP is on the same shadow stack.
> the second case relies on the described stack switch abi rule.
>
> > > > +L(restore_shadow_stack):
> > > > + /* Restore the target shadow stack. */
> > > > + rstorssp -8(%rcx)
> > >
> > > i think a restore token is needed on the old shadow stack,
> > > so if there was a setjmp on that stack one can resume to it.
> >
> > Who will put a restore token on shadow stack when user context
> > isn't used? If kernel does it, CALL will override the restore token
> > when the end of shadow stack is reached.
>
> anybody who switches away from the stack has to place a token,
> this is simply the abi.
>
> if no token is placed that means all the old stack frames are
> not available for switching. (e.g. if the kernel does not place
> a token on syscall entry, then longjmp is not allowed to jump
> to the stack of another thread that happens to be in a syscall,
> which is totally reasonable and it's a good thing that we prevent
> such broken longjmp usage imo)
>
> you could design a different abi (e.g. one that relies on wrss),
> but i don't see the problem with the abi i'm describing.
>
>
The 12/15/2023 09:08, H.J. Lu wrote:
> On Fri, Dec 15, 2023 at 1:23 AM szabolcs.nagy@arm.com
> <szabolcs.nagy@arm.com> wrote:
> >
> > The 12/14/2023 09:40, H.J. Lu wrote:
> > > On Thu, Dec 14, 2023 at 9:13 AM szabolcs.nagy@arm.com
> > > > so the rule can be that if a user wants a stack to be resumable
> > > > then a restore token must be placed on that stack when switching
> > >
> > > That is fine.
> > >
> > > > away from it, if the token is not there then longjmp is ub and
> > > > may crash. (so no need to check for 0, such longjmp is a user error)
> > >
> > > We need to check for 0. Otherwise, all current setjmp tests segfault
> > > since there is no restore token on the target shadow stack.
> >
> > i don't understand this claim.
> >
> > any longjmp target ssp is either
> > - on the same stack: you can check targetssp == ssp
> > - or different stack: you can check *targetssp == restore token
> > as you scan the target ssp.
>
> longjmp doesn't know if the target SSP is on the same shadow stack.
>
it does if it scans.
for (;; targetssp--) {
if (targetssp == ssp) do_samestack();
if (*targetssp == restoretoken) do_differentstack();
}
the only problem i see is if the target shadow stack is
different from the current one and does not end in a restore
token. but i think that is a user error.
if we plan to introduce altshadowstack then this does not
work in case of shadow stack overflow because the overflowed
shadow stack cannot be jumped to even though in practice we
want that to work.
> > the second case relies on the described stack switch abi rule.
> >
> > > > > +L(restore_shadow_stack):
> > > > > + /* Restore the target shadow stack. */
> > > > > + rstorssp -8(%rcx)
> > > >
> > > > i think a restore token is needed on the old shadow stack,
> > > > so if there was a setjmp on that stack one can resume to it.
> > >
> > > Who will put a restore token on shadow stack when user context
> > > isn't used? If kernel does it, CALL will override the restore token
> > > when the end of shadow stack is reached.
> >
> > anybody who switches away from the stack has to place a token,
> > this is simply the abi.
> >
> > if no token is placed that means all the old stack frames are
> > not available for switching. (e.g. if the kernel does not place
> > a token on syscall entry, then longjmp is not allowed to jump
> > to the stack of another thread that happens to be in a syscall,
> > which is totally reasonable and it's a good thing that we prevent
> > such broken longjmp usage imo)
> >
> > you could design a different abi (e.g. one that relies on wrss),
> > but i don't see the problem with the abi i'm describing.
> >
> >
>
>
> --
> H.J.
On Mon, Dec 18, 2023 at 2:54 AM szabolcs.nagy@arm.com
<szabolcs.nagy@arm.com> wrote:
>
> The 12/15/2023 09:08, H.J. Lu wrote:
> > On Fri, Dec 15, 2023 at 1:23 AM szabolcs.nagy@arm.com
> > <szabolcs.nagy@arm.com> wrote:
> > >
> > > The 12/14/2023 09:40, H.J. Lu wrote:
> > > > On Thu, Dec 14, 2023 at 9:13 AM szabolcs.nagy@arm.com
> > > > > so the rule can be that if a user wants a stack to be resumable
> > > > > then a restore token must be placed on that stack when switching
> > > >
> > > > That is fine.
> > > >
> > > > > away from it, if the token is not there then longjmp is ub and
> > > > > may crash. (so no need to check for 0, such longjmp is a user error)
> > > >
> > > > We need to check for 0. Otherwise, all current setjmp tests segfault
> > > > since there is no restore token on the target shadow stack.
> > >
> > > i don't understand this claim.
> > >
> > > any longjmp target ssp is either
> > > - on the same stack: you can check targetssp == ssp
> > > - or different stack: you can check *targetssp == restore token
> > > as you scan the target ssp.
> >
> > longjmp doesn't know if the target SSP is on the same shadow stack.
> >
>
> it does if it scans.
>
> for (;; targetssp--) {
> if (targetssp == ssp) do_samestack();
> if (*targetssp == restoretoken) do_differentstack();
> }
>
> the only problem i see is if the target shadow stack is
> different from the current one and does not end in a restore
> token. but i think that is a user error.
Yes, it works. But it is hard to tell its performance overhead.
> if we plan to introduce altshadowstack then this does not
> work in case of shadow stack overflow because the overflowed
> shadow stack cannot be jumped to even though in practice we
> want that to work.
>
I'd like to support shadow stack in glibc 2.39. Since my patch
doesn't enable shadow stack by default, it doesn't have any
functionality impact on users. It allows us to evaluate shadow
stack support in all packages. We may need to use WRUSS
to enable shadow stack for some packages. But users and
developers can't see how shadow stack works if shadow stack
can't be turned on.
The 12/18/2023 11:06, H.J. Lu wrote:
> On Mon, Dec 18, 2023 at 2:54 AM szabolcs.nagy@arm.com
> <szabolcs.nagy@arm.com> wrote:
> > it does if it scans.
> >
> > for (;; targetssp--) {
> > if (targetssp == ssp) do_samestack();
> > if (*targetssp == restoretoken) do_differentstack();
> > }
> >
> > the only problem i see is if the target shadow stack is
> > different from the current one and does not end in a restore
> > token. but i think that is a user error.
>
> Yes, it works. But it is hard to tell its performance overhead.
>
> > if we plan to introduce altshadowstack then this does not
> > work in case of shadow stack overflow because the overflowed
> > shadow stack cannot be jumped to even though in practice we
> > want that to work.
> >
>
> I'd like to support shadow stack in glibc 2.39. Since my patch
> doesn't enable shadow stack by default, it doesn't have any
> functionality impact on users. It allows us to evaluate shadow
> stack support in all packages. We may need to use WRUSS
> to enable shadow stack for some packages. But users and
> developers can't see how shadow stack works if shadow stack
> can't be turned on.
ok.
> From 3dba6d876db6a47b66a680bb4aa85b1db63aa3f8 Mon Sep 17 00:00:00 2001
> From: "H.J. Lu" <hjl.tools@gmail.com>
> Date: Wed, 13 Dec 2023 17:50:47 -0800
> Subject: [PATCH] x86-64/cet: Check the restore token in longjmp
>
> setcontext and swapcontext put a restore token on the old shadow stack
> so that they switch to a different shadow stack when switching user
> contexts. When longjmp from a user context, the target shadow stack
> can be different from the current shadow stack and INCSSP can't be
> used to restore the shadow stack pointer to the target shadow stack.
> Update longjmp to search for a restore token. If found, use the token
> to restore the shadow stack pointer before using INCSSP to pop the
> shadow stack. Stop the token search and use INCSSP if the shadow stack
> entry value is the same as the current shadow stack pointer.
>
> It is a user error if there is a shadow stack switch without leaving a
> restore token on the old shadow stack.
looks good except missing saveprevssp below
> ---
> sysdeps/x86_64/__longjmp.S | 28 +++++++++++++++++++++++++++-
> 1 file changed, 27 insertions(+), 1 deletion(-)
>
> diff --git a/sysdeps/x86_64/__longjmp.S b/sysdeps/x86_64/__longjmp.S
> index 9ac075e0a8..b106affdcd 100644
> --- a/sysdeps/x86_64/__longjmp.S
> +++ b/sysdeps/x86_64/__longjmp.S
> @@ -63,9 +63,35 @@ ENTRY(__longjmp)
> /* Check and adjust the Shadow-Stack-Pointer. */
> /* Get the current ssp. */
> rdsspq %rax
> + /* Save the current ssp. */
> + movq %rax, %r10
> /* And compare it with the saved ssp value. */
> - subq SHADOW_STACK_POINTER_OFFSET(%rdi), %rax
> + movq SHADOW_STACK_POINTER_OFFSET(%rdi), %rcx
> + subq %rcx, %rax
> je L(skip_ssp)
> +
> +L(find_restore_token_loop):
> + /* Look for a restore token. */
> + movq -8(%rcx), %rbx
> + andq $-8, %rbx
> + cmpq %rcx, %rbx
> + /* Find the restore token. */
> + je L(restore_shadow_stack)
> +
> + /* Try the next slot. */
> + subq $8, %rcx
> + /* Stop if the current ssp is found. */
> + cmpq %rcx, %r10
> + je L(no_shadow_stack_token)
> + jmp L(find_restore_token_loop)
> +
> +L(restore_shadow_stack):
> + /* Restore the target shadow stack. */
> + rstorssp -8(%rcx)
> + rdsspq %rax
> + subq SHADOW_STACK_POINTER_OFFSET(%rdi), %rax
> +
i'd use saveprevssp in this case so the old shadow stack
remains resumable with a later longjmp.
> +L(no_shadow_stack_token):
> /* Count the number of frames to adjust and adjust it
> with incssp instruction. The instruction can adjust
> the ssp by [0..255] value only thus use a loop if
> --
> 2.43.0
>
On Tue, Dec 19, 2023 at 9:16 AM szabolcs.nagy@arm.com
<szabolcs.nagy@arm.com> wrote:
>
> The 12/18/2023 11:06, H.J. Lu wrote:
> > On Mon, Dec 18, 2023 at 2:54 AM szabolcs.nagy@arm.com
> > <szabolcs.nagy@arm.com> wrote:
> > > it does if it scans.
> > >
> > > for (;; targetssp--) {
> > > if (targetssp == ssp) do_samestack();
> > > if (*targetssp == restoretoken) do_differentstack();
> > > }
> > >
> > > the only problem i see is if the target shadow stack is
> > > different from the current one and does not end in a restore
> > > token. but i think that is a user error.
> >
> > Yes, it works. But it is hard to tell its performance overhead.
> >
> > > if we plan to introduce altshadowstack then this does not
> > > work in case of shadow stack overflow because the overflowed
> > > shadow stack cannot be jumped to even though in practice we
> > > want that to work.
> > >
> >
> > I'd like to support shadow stack in glibc 2.39. Since my patch
> > doesn't enable shadow stack by default, it doesn't have any
> > functionality impact on users. It allows us to evaluate shadow
> > stack support in all packages. We may need to use WRUSS
> > to enable shadow stack for some packages. But users and
> > developers can't see how shadow stack works if shadow stack
> > can't be turned on.
>
> ok.
>
> > From 3dba6d876db6a47b66a680bb4aa85b1db63aa3f8 Mon Sep 17 00:00:00 2001
> > From: "H.J. Lu" <hjl.tools@gmail.com>
> > Date: Wed, 13 Dec 2023 17:50:47 -0800
> > Subject: [PATCH] x86-64/cet: Check the restore token in longjmp
> >
> > setcontext and swapcontext put a restore token on the old shadow stack
> > so that they switch to a different shadow stack when switching user
> > contexts. When longjmp from a user context, the target shadow stack
> > can be different from the current shadow stack and INCSSP can't be
> > used to restore the shadow stack pointer to the target shadow stack.
> > Update longjmp to search for a restore token. If found, use the token
> > to restore the shadow stack pointer before using INCSSP to pop the
> > shadow stack. Stop the token search and use INCSSP if the shadow stack
> > entry value is the same as the current shadow stack pointer.
> >
> > It is a user error if there is a shadow stack switch without leaving a
> > restore token on the old shadow stack.
>
> looks good except missing saveprevssp below
>
> > ---
> > sysdeps/x86_64/__longjmp.S | 28 +++++++++++++++++++++++++++-
> > 1 file changed, 27 insertions(+), 1 deletion(-)
> >
> > diff --git a/sysdeps/x86_64/__longjmp.S b/sysdeps/x86_64/__longjmp.S
> > index 9ac075e0a8..b106affdcd 100644
> > --- a/sysdeps/x86_64/__longjmp.S
> > +++ b/sysdeps/x86_64/__longjmp.S
> > @@ -63,9 +63,35 @@ ENTRY(__longjmp)
> > /* Check and adjust the Shadow-Stack-Pointer. */
> > /* Get the current ssp. */
> > rdsspq %rax
> > + /* Save the current ssp. */
> > + movq %rax, %r10
> > /* And compare it with the saved ssp value. */
> > - subq SHADOW_STACK_POINTER_OFFSET(%rdi), %rax
> > + movq SHADOW_STACK_POINTER_OFFSET(%rdi), %rcx
> > + subq %rcx, %rax
> > je L(skip_ssp)
> > +
> > +L(find_restore_token_loop):
> > + /* Look for a restore token. */
> > + movq -8(%rcx), %rbx
> > + andq $-8, %rbx
> > + cmpq %rcx, %rbx
> > + /* Find the restore token. */
> > + je L(restore_shadow_stack)
> > +
> > + /* Try the next slot. */
> > + subq $8, %rcx
> > + /* Stop if the current ssp is found. */
> > + cmpq %rcx, %r10
> > + je L(no_shadow_stack_token)
> > + jmp L(find_restore_token_loop)
> > +
> > +L(restore_shadow_stack):
> > + /* Restore the target shadow stack. */
> > + rstorssp -8(%rcx)
> > + rdsspq %rax
> > + subq SHADOW_STACK_POINTER_OFFSET(%rdi), %rax
> > +
>
> i'd use saveprevssp in this case so the old shadow stack
> remains resumable with a later longjmp.
Good idea. Will add it. I will submit it as a separate patch
after my current shadow stack patches have been merged.
Thanks.
> > +L(no_shadow_stack_token):
> > /* Count the number of frames to adjust and adjust it
> > with incssp instruction. The instruction can adjust
> > the ssp by [0..255] value only thus use a loop if
> > --
> > 2.43.0
> >
>
@@ -44,6 +44,7 @@ CFLAGS-tst-cet-vfork-1.c += -mshstk
endif
ifeq ($(subdir),stdlib)
+sysdep_routines += allocate-shadow-stack
tests += tst-cet-setcontext-1
CFLAGS-tst-cet-setcontext-1.c += -mshstk
endif
new file mode 100644
@@ -0,0 +1,54 @@
+/* Helper function to allocate shadow stack.
+ Copyright (C) 2023 Free Software Foundation, Inc.
+ This file is part of the GNU C Library.
+
+ The GNU C Library is free software; you can redistribute it and/or
+ modify it under the terms of the GNU Lesser General Public
+ License as published by the Free Software Foundation; either
+ version 2.1 of the License, or (at your option) any later version.
+
+ The GNU C Library is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ Lesser General Public License for more details.
+
+ You should have received a copy of the GNU Lesser General Public
+ License along with the GNU C Library; if not, see
+ <https://www.gnu.org/licenses/>. */
+
+#include <sysdep.h>
+#include <stdint.h>
+#include <errno.h>
+#include <sys/mman.h>
+#include <libc-pointer-arith.h>
+#include <allocate-shadow-stack.h>
+
+/* NB: This can be treated as a syscall by caller. */
+
+#ifndef __x86_64__
+__attribute__ ((regparm (2)))
+#endif
+long int
+__allocate_shadow_stack (size_t stack_size,
+ shadow_stack_size_t *child_stack)
+{
+#ifdef __NR_map_shadow_stack
+ size_t shadow_stack_size
+ = stack_size >> STACK_SIZE_TO_SHADOW_STACK_SIZE_SHIFT;
+ /* Align shadow stack to 8 bytes. */
+ shadow_stack_size = ALIGN_UP (shadow_stack_size, 8);
+ void *shadow_stack = (void *)INLINE_SYSCALL_CALL
+ (map_shadow_stack, NULL, shadow_stack_size, SHADOW_STACK_SET_TOKEN);
+ /* Report the map_shadow_stack error. */
+ if (shadow_stack == MAP_FAILED)
+ return -errno;
+
+ /* Save the shadow stack base and size on child stack. */
+ child_stack[0] = (uintptr_t) shadow_stack;
+ child_stack[1] = shadow_stack_size;
+
+ return 0;
+#else
+ return -ENOSYS;
+#endif
+}
new file mode 100644
@@ -0,0 +1,27 @@
+/* Helper function to allocate shadow stack.
+ Copyright (C) 2023 Free Software Foundation, Inc.
+ This file is part of the GNU C Library.
+
+ The GNU C Library is free software; you can redistribute it and/or
+ modify it under the terms of the GNU Lesser General Public
+ License as published by the Free Software Foundation; either
+ version 2.1 of the License, or (at your option) any later version.
+
+ The GNU C Library is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ Lesser General Public License for more details.
+
+ You should have received a copy of the GNU Lesser General Public
+ License along with the GNU C Library; if not, see
+ <https://www.gnu.org/licenses/>. */
+
+#include <ucontext.h>
+
+typedef __typeof (((ucontext_t *) 0)->__ssp[0]) shadow_stack_size_t;
+
+extern long int __allocate_shadow_stack (size_t, shadow_stack_size_t *)
+#ifndef __x86_64__
+ __attribute__ ((regparm (2)))
+#endif
+ attribute_hidden;
@@ -27,6 +27,11 @@
#define MAP_32BIT 0x40 /* Only give out 32-bit addresses. */
#define MAP_ABOVE4G 0x80 /* Only map above 4GB. */
+#ifdef __USE_MISC
+/* Set up a restore token in the newly allocatd shadow stack */
+# define SHADOW_STACK_SET_TOKEN 0x1
+#endif
+
#include <bits/mman-map-flags-generic.h>
/* Include generic Linux declarations. */
@@ -23,10 +23,15 @@
static inline int __attribute__ ((always_inline))
get_cet_status (void)
{
- unsigned long long cet_status[3];
- if (INTERNAL_SYSCALL_CALL (arch_prctl, ARCH_CET_STATUS, cet_status) == 0)
- return cet_status[0];
- return 0;
+ unsigned long long kernel_feature;
+ unsigned int status = 0;
+ if (INTERNAL_SYSCALL_CALL (arch_prctl, ARCH_SHSTK_STATUS,
+ &kernel_feature) == 0)
+ {
+ if ((kernel_feature & ARCH_SHSTK_SHSTK) != 0)
+ status = GNU_PROPERTY_X86_FEATURE_1_SHSTK;
+ }
+ return status;
}
# ifndef SHARED
@@ -21,12 +21,20 @@
static inline int __attribute__ ((always_inline))
dl_cet_disable_cet (unsigned int cet_feature)
{
- return (int) INTERNAL_SYSCALL_CALL (arch_prctl, ARCH_CET_DISABLE,
- cet_feature);
+ if (cet_feature != GNU_PROPERTY_X86_FEATURE_1_SHSTK)
+ return -1;
+ long long int kernel_feature = ARCH_SHSTK_SHSTK;
+ return (int) INTERNAL_SYSCALL_CALL (arch_prctl, ARCH_SHSTK_DISABLE,
+ kernel_feature);
}
static inline int __attribute__ ((always_inline))
-dl_cet_lock_cet (void)
+dl_cet_lock_cet (unsigned int cet_feature)
{
- return (int) INTERNAL_SYSCALL_CALL (arch_prctl, ARCH_CET_LOCK, 0);
+ if (cet_feature != GNU_PROPERTY_X86_FEATURE_1_SHSTK)
+ return -1;
+ /* Lock all SHSTK features. */
+ long long int kernel_feature = -1;
+ return (int) INTERNAL_SYSCALL_CALL (arch_prctl, ARCH_SHSTK_LOCK,
+ kernel_feature);
}
@@ -4,24 +4,19 @@
#include_next <asm/prctl.h>
-#ifndef ARCH_CET_STATUS
-/* CET features:
- IBT: GNU_PROPERTY_X86_FEATURE_1_IBT
- SHSTK: GNU_PROPERTY_X86_FEATURE_1_SHSTK
- */
-/* Return CET features in unsigned long long *addr:
- features: addr[0].
- shadow stack base address: addr[1].
- shadow stack size: addr[2].
- */
-# define ARCH_CET_STATUS 0x3001
-/* Disable CET features in unsigned int features. */
-# define ARCH_CET_DISABLE 0x3002
-/* Lock all CET features. */
-# define ARCH_CET_LOCK 0x3003
-/* Allocate a new shadow stack with unsigned long long *addr:
- IN: requested shadow stack size: *addr.
- OUT: allocated shadow stack address: *addr.
- */
-# define ARCH_CET_ALLOC_SHSTK 0x3004
-#endif /* ARCH_CET_STATUS */
+#ifndef ARCH_SHSTK_ENABLE
+/* Enable SHSTK features in unsigned long int features. */
+# define ARCH_SHSTK_ENABLE 0x5001
+/* Disable SHSTK features in unsigned long int features. */
+# define ARCH_SHSTK_DISABLE 0x5002
+/* Lock SHSTK features in unsigned long int features. */
+# define ARCH_SHSTK_LOCK 0x5003
+/* Unlock SHSTK features in unsigned long int features. */
+# define ARCH_SHSTK_UNLOCK 0x5004
+/* Return SHSTK features in unsigned long int features. */
+# define ARCH_SHSTK_STATUS 0x5005
+
+/* ARCH_SHSTK_ features bits */
+# define ARCH_SHSTK_SHSTK 0x1
+# define ARCH_SHSTK_WRSS 0x2
+#endif
@@ -87,15 +87,14 @@ do_test (void)
ctx[4].uc_link = &ctx[0];
makecontext (&ctx[4], (void (*) (void)) f1, 0);
- /* NB: When shadow stack is enabled, makecontext calls arch_prctl
- with ARCH_CET_ALLOC_SHSTK to allocate a new shadow stack which
- can be unmapped. The base address and size of the new shadow
- stack are returned in __ssp[1] and __ssp[2]. makecontext is
- called for CTX1, CTX3 and CTX4. But only CTX1 is used. New
- shadow stacks are allocated in the order of CTX3, CTX1, CTX4.
- It is very likely that CTX1's shadow stack is placed between
- CTX3 and CTX4. We munmap CTX3's and CTX4's shadow stacks to
- create gaps above and below CTX1's shadow stack. We check
+ /* NB: When shadow stack is enabled, makecontext calls map_shadow_stack
+ to allocate a new shadow stack which can be unmapped. The base
+ address and size of the new shadow stack are returned in __ssp[1]
+ and __ssp[2]. makecontext is called for CTX1, CTX3 and CTX4. But
+ only CTX1 is used. New shadow stacks are allocated in the order
+ of CTX3, CTX1, CTX4. It is very likely that CTX1's shadow stack is
+ placed between CTX3 and CTX4. We munmap CTX3's and CTX4's shadow
+ stacks to create gaps above and below CTX1's shadow stack. We check
that setcontext CTX1 works correctly in this case. */
if (_get_ssp () != 0)
{
@@ -24,20 +24,14 @@
/* Use CALL to push __start_context onto the new stack as well as the new
shadow stack. RDI points to ucontext:
Incoming:
- __ssp[0]: The original caller's shadow stack pointer.
- __ssp[1]: The size of the new shadow stack.
- __ssp[2]: The size of the new shadow stack.
- Outgoing:
__ssp[0]: The new shadow stack pointer.
__ssp[1]: The base address of the new shadow stack.
__ssp[2]: The size of the new shadow stack.
*/
ENTRY(__push___start_context)
- /* Save the pointer to ucontext. */
- movq %rdi, %r9
/* Get the original shadow stack pointer. */
- rdsspq %r8
+ rdsspq %rcx
/* Save the original stack pointer. */
movq %rsp, %rdx
/* Load the top of the new stack into RSI. */
@@ -45,24 +39,12 @@ ENTRY(__push___start_context)
/* Add 8 bytes to RSI since CALL will push the 8-byte return
address onto stack. */
leaq 8(%rsi), %rsp
- /* Allocate the new shadow stack. The size of the new shadow
- stack is passed in __ssp[1]. */
- lea (oSSP + 8)(%rdi), %RSI_LP
- movl $ARCH_CET_ALLOC_SHSTK, %edi
- movl $__NR_arch_prctl, %eax
- /* The new shadow stack base is returned in __ssp[1]. */
- syscall
- testq %rax, %rax
- jne L(hlt) /* This should never happen. */
-
- /* Get the size of the new shadow stack. */
- movq 8(%rsi), %rdi
-
- /* Get the base address of the new shadow stack. */
- movq (%rsi), %rsi
-
+ /* The size of the new shadow stack is stored in __ssp[2]. */
+ mov (oSSP + 16)(%rdi), %RSI_LP
+ /* The new shadow stack base is stored in __ssp[1]. */
+ mov (oSSP + 8)(%rdi), %RAX_LP
/* Use the restore stoken to restore the new shadow stack. */
- rstorssp -8(%rsi, %rdi)
+ rstorssp -8(%rax, %rsi)
/* Save the restore token on the original shadow stack. */
saveprevssp
@@ -73,18 +55,12 @@ ENTRY(__push___start_context)
jmp __start_context
1:
- /* Get the new shadow stack pointer. */
- rdsspq %rdi
-
/* Use the restore stoken to restore the original shadow stack. */
- rstorssp -8(%r8)
+ rstorssp -8(%rcx)
/* Save the restore token on the new shadow stack. */
saveprevssp
- /* Store the new shadow stack pointer in __ssp[0]. */
- movq %rdi, oSSP(%r9)
-
/* Restore the original stack. */
mov %rdx, %rsp
ret
@@ -58,35 +58,15 @@ ENTRY(__getcontext)
testl $X86_FEATURE_1_SHSTK, %fs:FEATURE_1_OFFSET
jz L(no_shstk)
- /* Save RDI in RDX which won't be clobbered by syscall. */
- movq %rdi, %rdx
-
xorl %eax, %eax
cmpq %fs:SSP_BASE_OFFSET, %rax
jnz L(shadow_stack_bound_recorded)
- /* Get the base address and size of the default shadow stack
- which must be the current shadow stack since nothing has
- been recorded yet. */
- sub $24, %RSP_LP
- mov %RSP_LP, %RSI_LP
- movl $ARCH_CET_STATUS, %edi
- movl $__NR_arch_prctl, %eax
- syscall
- testq %rax, %rax
- jz L(continue_no_err)
-
- /* This should never happen. */
- hlt
-
-L(continue_no_err):
- /* Record the base of the current shadow stack. */
- movq 8(%rsp), %rax
+ /* When the shadow stack base is unset, the default shadow
+ stack is in use. Use the current shadow stack pointer
+ as the marker for the default shadow stack. */
+ rdsspq %rax
movq %rax, %fs:SSP_BASE_OFFSET
- add $24, %RSP_LP
-
- /* Restore RDI. */
- movq %rdx, %rdi
L(shadow_stack_bound_recorded):
/* Get the current shadow stack pointer. */
@@ -94,7 +74,7 @@ L(shadow_stack_bound_recorded):
/* NB: Save the caller's shadow stack so that we can jump back
to the caller directly. */
addq $8, %rax
- movq %rax, oSSP(%rdx)
+ movq %rax, oSSP(%rdi)
/* Save the current shadow stack base in ucontext. */
movq %fs:SSP_BASE_OFFSET, %rax
@@ -24,6 +24,8 @@
# include <pthread.h>
# include <libc-pointer-arith.h>
# include <sys/prctl.h>
+# include <sys/mman.h>
+# include <allocate-shadow-stack.h>
#endif
#include "ucontext_i.h"
@@ -88,23 +90,24 @@ __makecontext (ucontext_t *ucp, void (*func) (void), int argc, ...)
if ((feature_1 & X86_FEATURE_1_SHSTK) != 0)
{
/* Shadow stack is enabled. We need to allocate a new shadow
- stack. */
- unsigned long ssp_size = (((uintptr_t) sp
- - (uintptr_t) ucp->uc_stack.ss_sp)
- >> STACK_SIZE_TO_SHADOW_STACK_SIZE_SHIFT);
- /* Align shadow stack to 8 bytes. */
- ssp_size = ALIGN_UP (ssp_size, 8);
-
- ucp->__ssp[1] = ssp_size;
- ucp->__ssp[2] = ssp_size;
-
- /* Call __push___start_context to allocate a new shadow stack,
- push __start_context onto the new stack as well as the new
- shadow stack. NB: After __push___start_context returns,
+ stack. NB:
ucp->__ssp[0]: The new shadow stack pointer.
ucp->__ssp[1]: The base address of the new shadow stack.
ucp->__ssp[2]: The size of the new shadow stack.
*/
+ long int ret
+ = __allocate_shadow_stack (((uintptr_t) sp
+ - (uintptr_t) ucp->uc_stack.ss_sp),
+ &ucp->__ssp[1]);
+ if (ret != 0)
+ {
+ /* FIXME: What should we do? */
+ abort ();
+ }
+
+ ucp->__ssp[0] = ucp->__ssp[1] + ucp->__ssp[2] - 8;
+ /* Call __push___start_context to push __start_context onto the new
+ stack as well as the new shadow stack. */
__push___start_context (ucp);
}
else
@@ -109,25 +109,11 @@ ENTRY(__swapcontext)
cmpq %fs:SSP_BASE_OFFSET, %rax
jnz L(shadow_stack_bound_recorded)
- /* Get the base address and size of the default shadow stack
- which must be the current shadow stack since nothing has
- been recorded yet. */
- sub $24, %RSP_LP
- mov %RSP_LP, %RSI_LP
- movl $ARCH_CET_STATUS, %edi
- movl $__NR_arch_prctl, %eax
- syscall
- testq %rax, %rax
- jz L(continue_no_err)
-
- /* This should never happen. */
- hlt
-
-L(continue_no_err):
- /* Record the base of the current shadow stack. */
- movq 8(%rsp), %rax
+ /* When the shadow stack base is unset, the default shadow
+ stack is in use. Use the current shadow stack pointer
+ as the marker for the default shadow stack. */
+ rdsspq %rax
movq %rax, %fs:SSP_BASE_OFFSET
- add $24, %RSP_LP
L(shadow_stack_bound_recorded):
/* If we unwind the stack, we can't undo stack unwinding. Just
@@ -1121,8 +1121,9 @@ no_cpuid:
# ifndef SHARED
/* Check if IBT and SHSTK are enabled by kernel. */
- if ((cet_status & GNU_PROPERTY_X86_FEATURE_1_IBT)
- || (cet_status & GNU_PROPERTY_X86_FEATURE_1_SHSTK))
+ if ((cet_status
+ & (GNU_PROPERTY_X86_FEATURE_1_IBT
+ | GNU_PROPERTY_X86_FEATURE_1_SHSTK)))
{
/* Disable IBT and/or SHSTK if they are enabled by kernel, but
disabled by environment variable:
@@ -1131,9 +1132,11 @@ no_cpuid:
*/
unsigned int cet_feature = 0;
if (!CPU_FEATURE_USABLE (IBT))
- cet_feature |= GNU_PROPERTY_X86_FEATURE_1_IBT;
+ cet_feature |= (cet_status
+ & GNU_PROPERTY_X86_FEATURE_1_IBT);
if (!CPU_FEATURE_USABLE (SHSTK))
- cet_feature |= GNU_PROPERTY_X86_FEATURE_1_SHSTK;
+ cet_feature |= (cet_status
+ & GNU_PROPERTY_X86_FEATURE_1_SHSTK);
if (cet_feature)
{
@@ -1148,7 +1151,9 @@ no_cpuid:
lock CET if IBT or SHSTK is enabled permissively. */
if (GL(dl_x86_feature_control).ibt != cet_permissive
&& GL(dl_x86_feature_control).shstk != cet_permissive)
- dl_cet_lock_cet ();
+ dl_cet_lock_cet (GL(dl_x86_feature_1)
+ & (GNU_PROPERTY_X86_FEATURE_1_IBT
+ | GNU_PROPERTY_X86_FEATURE_1_SHSTK));
}
# endif
}
@@ -201,7 +201,7 @@ dl_cet_check_startup (struct link_map *m, struct dl_cet_info *info)
feature_1_lock |= GNU_PROPERTY_X86_FEATURE_1_SHSTK;
if (feature_1_lock != 0
- && dl_cet_lock_cet () != 0)
+ && dl_cet_lock_cet (feature_1_lock) != 0)
_dl_fatal_printf ("%s: can't lock CET\n", info->program);
}
@@ -60,7 +60,7 @@ typedef struct
void *__private_tm[4];
/* GCC split stack support. */
void *__private_ss;
- /* The lowest address of shadow stack, */
+ /* The marker for the current shadow stack. */
unsigned long long int ssp_base;
/* Must be kept even if it is no longer used by glibc since programs,
like AddressSanitizer, depend on the size of tcbhead_t. */