On Tue, Sep 1, 2020 at 10:23 AM Yu, Yu-cheng [off-list ref] wrote:

On 9/1/2020 3:28 AM, Dave Martin wrote:

quoted

On Thu, Aug 27, 2020 at 06:26:11AM -0700, H.J. Lu wrote:

quoted

On Wed, Aug 26, 2020 at 12:57 PM Dave Hansen [off-list ref] wrote:

quoted

On 8/26/20 11:49 AM, Yu, Yu-cheng wrote:

quoted

quoted

I would expect things like Go and various JITs to call it directly.

If we wanted to be fancy and add a potentially more widely useful
syscall, how about:

mmap_special(void *addr, size_t length, int prot, int flags, int type);

Where type is something like MMAP_SPECIAL_X86_SHSTK.  Fundamentally,
this is really just mmap() except that we want to map something a bit
magical, and we don't want to require opening a device node to do it.

One benefit of MMAP_SPECIAL_* is there are more free bits than MAP_*.
Does ARM have similar needs for memory mapping, Dave?

No idea.

But, mmap_special() is *basically* mmap2() with extra-big flags space.
I suspect it will grow some more uses on top of shadow stacks.  It could
have, for instance, been used to allocate MPX bounds tables.

There is no reason we can't use

long arch_prctl (int, unsigned long, unsigned long, unsigned long, ..);

for ARCH_X86_CET_MMAP_SHSTK.   We just need to use

syscall (SYS_arch_prctl, ARCH_X86_CET_MMAP_SHSTK, ...);

For arm64 (and sparc etc.) we continue to use the regular mmap/mprotect
family of calls.  One or two additional arch-specific mmap flags are
sufficient for now.

Is x86 definitely not going to fit within those calls?

That can work for x86.  Andy, what if we create PROT_SHSTK, which can
been seen only from the user.  Once in kernel, it is translated to
VM_SHSTK.  One question for mremap/mprotect is, do we allow a normal
data area to become shadow stack?

I'm unconvinced that we want to use a somewhat precious PROT_ or VM_
bit for this.  Using a flag bit makes sense if we expect anyone to
ever map an fd or similar as a shadow stack, but that seems a bit odd
in the first place.  To me, it seems more logical for a shadow stack
to be a special sort of mapping with a special vm_ops, not a normal
mapping with a special flag set.  Although I realize that we want
shadow stacks to work like anonymous memory with respect to fork().
Dave?

--Andy