<story><title>OpenBSD system-call-origin verification</title><url>https://lwn.net/Articles/806776/</url></story><parent_chain></parent_chain><comment><author>quotemstr</author><text>I strongly support this policy not only for security, but also for general operating system robustness. Linux is pretty much the only system that places the ABI compatibility boundary and the machine privilege level boundary in the same place in the stack. I think that&amp;#x27;s the wrong place: it pushes a lot of complexity that could be in userspace into the kernel, because the kernel is the first place past the ABI break. Linux would be better if nobody except libc were allowed to make system calls and we just made libc (or a giant VDSO) the ABI support boundary.&lt;p&gt;We should at the very least have a VDSO for every system call. There should be &lt;i&gt;some&lt;/i&gt; opportunity to run code in userspace before a privilege transition. Doing so would give us a lot more flexibility than we have now.&lt;p&gt;For example, consider socketcall(2): for a long time, all Linux socket system calls (like recvmsg) were multiplexed through a single system call. A few years ago, the kernel community realized that this multiplexing was a bad idea and made individual system calls for all the traditional socket operations. But since we have to support old programs, we have socketcall(2) &lt;i&gt;and&lt;/i&gt; the new system calls in the kernel. Why should we?&lt;p&gt;If the ABI support level had been libc all along, we could have changed the system call strategy (from multiplexing to fine-grained calls) transparently without bloating the kernel with compatibility code.</text></comment>
<story><title>OpenBSD system-call-origin verification</title><url>https://lwn.net/Articles/806776/</url></story><parent_chain></parent_chain><comment><author>gok</author><text>This is a pretty weak security mitigation since any ROP attack will typically achieve return-to-libc anyway, but yelling at people who make syscalls directly is good.</text></comment>