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. --Andy
