> I'm not very familiar with low level work and exploits, but aren't syscalls the API for the kernel itself? No. The kernel doesn't call syscalls itself. It pr

> I'm not very familiar with low level work and exploits, but aren't syscalls the API for the kernel itself? No. The kernel doesn't call syscalls itself. It provides them for applications. Just to clarify a potential misunderstanding. The kernel and userspace run at different "hardware" privilege levels (ring0<=>ring3). Userspace applications cannot simply call the kernel API directly, they must "trap" into the kernel to perform some pre-defined service request, aka. System calls. There are usually a few hundred or more of these, like e.g. read(2)/write(2). They are also generally exposed via libc wrappers (but not always) or via the indirect syscall(3) function. But it is also technically possible to directly encode the trap instruction, for example on x86 "int $0x80" or amd64 "syscall" with the desired syscall index. This is the part OpenBSD is proposing to lock down. The low-level syscall ABI has always been unstable, meaning it can be changed incompatibility, and libc is the more-stable interface applications should be using. With that out of the way.. > Is it possible to authorize arbitrary code, or is access to msyscall (via libc or otherwise) restricted outside of boot? msyscall(2) can only be called /once/ per-process, e.g. by the ld.so dynamic linker. This is used to indicate where libc is mapped (libraries are mapped randomly) to the kernel so it can permit that area to make syscalls.