Re: [PATCH v7 33/41] x86/shstk: Introduce map_shadow_stack syscall

[Edgecombe, Rick P]

On Thu, 2023-03-02 at 17:22 +0000, Szabolcs Nagy wrote:
> The 02/27/2023 14:29, Rick Edgecombe wrote:
> > Previously, a new PROT_SHADOW_STACK was attempted,
> 
> ...
> > So rather than repurpose two existing syscalls (mmap, madvise) that
> > don't
> > quite fit, just implement a new map_shadow_stack syscall to allow
> > userspace to map and setup new shadow stacks in one step. While
> > ucontext
> > is the primary motivator, userspace may have other unforeseen
> > reasons to
> > setup it's own shadow stacks using the WRSS instruction. Towards
> > this
> > provide a flag so that stacks can be optionally setup securely for
> > the
> > common case of ucontext without enabling WRSS. Or potentially have
> > the
> > kernel set up the shadow stack in some new way.
> 
> ...
> > The following example demonstrates how to create a new shadow stack
> > with
> > map_shadow_stack:
> > void *shstk = map_shadow_stack(addr, stack_size,
> > SHADOW_STACK_SET_TOKEN);
> 
> i think
> 
> mmap(addr, size, PROT_READ, MAP_ANON|MAP_SHADOW_STACK, -1, 0);
> 
> could do the same with less disruption to users (new syscalls
> are harder to deal with than new flags). it would do the
> guard page and initial token setup too (there is no flag for
> it but could be squeezed in).
> 
> most of the mmap features need not be available (EINVAL) when
> MAP_SHADOW_STACK is specified.
> 
> the main drawback is running out of mmap flags so extension
> is limited. (but the new syscall has limitations too).

Deepak Gupta (working on riscv shadow stack) asked something similar.
Can you see if this thread answers your questions?

https://lore.kernel.org/lkml/20230223000340.GB945966@xxxxxxxxxxxxxxxxxxxxx/