On Wed, Aug 26, 2020 at 11:49 AM Yu, Yu-cheng <yu-cheng.yu@xxxxxxxxx> wrote: > > On 8/26/2020 10:04 AM, Andy Lutomirski wrote: > > On Wed, Aug 26, 2020 at 9:52 AM Florian Weimer <fweimer@xxxxxxxxxx> wrote: > >> > >> * Dave Martin: > >> > >>> On Tue, Aug 25, 2020 at 04:34:27PM -0700, Yu, Yu-cheng wrote: > >>>> On 8/25/2020 4:20 PM, Dave Hansen wrote: > >>>>> On 8/25/20 2:04 PM, Yu, Yu-cheng wrote: > >>>>>>>> I think this is more arch-specific. Even if it becomes a new syscall, > >>>>>>>> we still need to pass the same parameters. > >>>>>>> > >>>>>>> Right, but without the copying in and out of memory. > >>>>>>> > >>>>>> Linux-api is already on the Cc list. Do we need to add more people to > >>>>>> get some agreements for the syscall? > >>>>> What kind of agreement are you looking for? I'd suggest just coding it > >>>>> up and posting the patches. Adding syscalls really is really pretty > >>>>> straightforward and isn't much code at all. > >>>>> > >>>> > >>>> Sure, I will do that. > >>> > >>> Alternatively, would a regular prctl() work here? > >> > >> Is this something appliation code has to call, or just the dynamic > >> loader? > >> > >> prctl in glibc is a variadic function, so if there's a mismatch between > >> the kernel/userspace syscall convention and the userspace calling > >> convention (for variadic functions) for specific types, it can't be made > >> to work in a generic way. > >> > >> The loader can use inline assembly for system calls and does not have > >> this issue, but applications would be implcated by it. > >> > > > > 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? > arch/arm64/include/uapi/asm/mman.h: #define PROT_BTI 0x10 /* BTI guarded page */ -- H.J.