2 ms·
The Linux approach to system call stability is awful. I've written about it extensively before. See this thread [1]. The gist of it is that a system doesn't nee
by quotemstr 7y ago
The Linux approach to system call stability is awful. I've written about it extensively before. See this thread [1]. The gist of it is that a system doesn't need to place the ABI support boundary at exactly the same page as the ring3-to-ring0 boundary, and that Linux does is 1) basically shipping the org chart, and 2) harmful in all sorts of ways.
The right way to do OS ABI stability is to require that system calls go through some user-space library before executing a privilege transition. This way, the kernel's interface can change as needed without breaking existing userland binaries. Windows gets this right: system calls go through ntdll.dll. Fuchsia gets this right as well: they don't have an ntdll.dll, but they have a huge vdso that amounts to the same thing.
If I had my way, Linux would take the Fuchsia approach: require every system call go through a vdso.
"But golang!" and "but I have multiple libcs!" and "but my static linking!" are not valid excuses. Windows also has Go and it also have multiple libcs and the NT kernel isn't forced to maintain decades of userland-facing crud.
As for static linking: you can statically link the world if you'd like, but you can do that and still call through a vdso or load the platform libc.
[1] https://news.ycombinator.com/item?id=20854857 https://news.ycombinator.com/item?id=20854857
- wtallis 7y agoHow exactly does a ntdll/vdso approach make it easier to preserve binary compatibility? It obviously moves the place at which binary compatibility needs to be preserved, but I'm not seeing how that move makes maintenance easier, unless you're implying that the userspace portion would not be the responsibility of the kernel developers.
- quotemstr 7y agoUser space has a lot more flexibility than the kernel when it comes to implementing ABIs. For example, Linux has to maintain a relatively large table of system calls for legacy reasons. (Consider socketcall(2)). Legacy "system calls" provided by a VDSO or ntdll.dll-like mechanism are just tiny regular functions with no special security or performance implications.
- wtallis 7y ago>Legacy "system calls" provided by a VDSO or ntdll.dll-like mechanism are just tiny regular functions with no special security or performance implications. Are you saying that wrapper code implementing an old interface by wrapping around a new interface is easier to do correctly in userspace than in the kernel itself? I think I need you to be more concrete in pointing to a specific performance penalty or avoidable maintenance burden.
- quotemstr 7y ago> Are you saying that wrapper code implementing an old interface by wrapping around a new interface is easier to do correctly in userspace than in the kernel itself? Yes. > I think I need you to be more concrete in pointing to a specific performance penalty or avoidable maintenance burden. I already did: socketcall. And NT does all 32-bit compatibility in userspace.
- wtallis 7y ago> I already did: socketcall Got anything that applies to modern platforms or recent kernel versions? Also, does socketcall actually have higher overhead than doing a similar dispatch in userspace, or does it just mean you get a cache miss slightly later in the process? (You could try elucidating an actual argument rather than just naming a syscall and assuming that the rest of your argument is obvious.) > And NT does all 32-bit compatibility in userspace. So? Is it faster to do that in userspace than in the kernel?