On 9/1/2020 3:28 AM, Dave Martin wrote:
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 <dave.hansen@xxxxxxxxx> wrote:
On 8/26/20 11:49 AM, Yu, Yu-cheng wrote:
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?
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.
If we use the approach above, then we don't need arch_prctl changes.
Thanks,
Yu-cheng
