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/
