Re:OpenBSD system-call-origin verification
by saagarjha on Sunday December 22, 2019 @08:21PM
(#21860832)
> We should have a VDSO for every system call.
This doesn't really make sense; the vDSO only works for system calls that do nothing but read a value from the kernel and return it to userspace.
Re:OpenBSD system-call-origin verification
by quotemstr on Sunday December 22, 2019 @08:25PM
(#21860854)
Not the case. Some VDSOs just forward to regular system calls. Try clock_gettime with CLOCK_BOOTTIME sometime. (I need to send a patch to fix this. Maybe over Christmas.)
Requiring that every system call go through a VDSO would be great because it would give us a "hook" for changing system behavior before entering the kernel, which is a good thing, because in the age of speculative execution mitigations, entering the kernel is expensive, just like in the days of yore.
Re:OpenBSD system-call-origin verification
by saagarjha on Sunday December 22, 2019 @08:46PM
(#21860926)
On my computer I ended up going through a rdtsc instead of a syscall…
We should at the very least have a VDSO for every system call. There should be some opportunity to run code in userspace before a privilege transition. Doing so would give us a lot more flexibility than we have now.
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) and the new system calls in the kernel. Why should we?
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.