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

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?

For now, I can't see what arg[2] is used for (and hence the type
argument of mmap_special()), but I haven't dug through the whole series.

Cheers
---Dave