Hacker News Reader

Comment by matheusmoreira | Hacker News Reader

Yes! The difference is on Linux a shared library is not actually required for kernel system calls. The binary interface is stable and will not change.

https://github.com/torvalds/linux/blob/master/Documentation/...

On Windows and other operating systems, things such as system call numbers can and do change. There's no way to interface with the kernel without linking to vendor libraries.

So on Linux you can ditch libc and write your own code. A Rust liblinux is definitely possible, I tested it. You can even have a compiler generate the system calls for you! It just needs to support the simple calling convention. No libraries necessary. I've seen a project that does just that:

https://github.com/titzer/virgil

View on HN

It's indeed possible! I and others are building a Rust version of this:

https://github.com/sunfishcode/mustang

It supports threads, filesystem, networking, and more!

The library for making Linux system calls is:

https://github.com/bytecodealliance/rustix

Amazing!! Rust safety all the way up to the Linux system calls, and no legacy cruft like errno anywhere. That's the sort of project I had in mind. I'm so glad I'm not insane for imagining things like this. It would be so great to see a 100% Rust or Lisp or Zig user space built on top of Linux. Would be a lot more interesting than the same old POSIX user space every distribution ships with...

I mean, I also can call functions from kernel32.dll on Windows without need of any libc, and the ABI is stable and will not change; and if/when MS decides to change the actual mechanism of switching into the kernel mode, or decide to move some stuff from the kernel into the user space ― they can, and I don't have to worry about that (and recompile my apps) because it's all abstracted away! "Fix it once in the shared library, and all its clients will benefit automatically".

On Linux, however, we have, for example, glibc on one hand which claims that it doesn't have a goal of forwarding all of the Linux's syscall, and several failed initiatives on the other hand to allow the user's code to perform syscalls only from inside of glibc (which spells doom to anything that doesn't use libc, e.g. Golang) because of security reasons. And the history of still having to support INT 80h together with SYSCALL on x64 on the third hand.

> several failed initiatives on the other hand to allow the user's code to perform syscalls only from inside of glibc (which spells doom to anything that doesn't use libc, e.g. Golang) because of security reasons

I didn't know about these efforts. Please elaborate.

OpenBSD does it already [0], see also discussions here on HN at [1]. Thankfully, the push to implement something like that in Linux wasn't strong enough. By the way, notice how questions "why do I have to go through an OS-approved C runtime even if I write in some other language?" are responded with "Oh come on, in the end, everything is built on top of libc".

The problem, again, is not that this kernel-entry interface is factored out into a separate shared library; the problem is that it's glued into a runtime of one specific programming language that now apparently everybody has to use.

[0] https://lwn.net/Articles/806776/

[1] https://news.ycombinator.com/item?id=21859612

> notice how questions "why do I have to go through an OS-approved C runtime even if I write in some other language?" are responded with "Oh come on, in the end, everything is built on top of libc"

Yeah. I don't like that. Just because that's the way it works now doesn't mean it must work that way forever. Because of its stable system calls, Linux doesn't impose any design on user space. People could theoretically rebuild the entire system in Lisp or Rust or something. Potential is limitless. Also, it's amazing that I can compile a freestanding program with zero dependencies and boot Linux straight into it.

> the problem is that it's glued into a runtime of one specific programming language that now apparently everybody has to use

I agree. It's a really hard problem to solve. Since it's based on the POSIX APIs there are tons of definitions and data types that are specified exclusively in C and its preprocessor. Not exactly accessible for other languages. The preprocessor macros in particular are extremely problematic. The only sane way to untangle those is to use a C compiler.

There's an interesting discussion in that thread you linked. What if the vDSO was the entry point for all system calls? That would certainly be interesting.

I think the vDSO ABI is underspecified. It's just the C ABI, whatever that means on your system. This can cause bugs due to assumptions. For example, this Go bug happened because Go called hardened versions of the vDSO functions with insufficient stack space:

https://news.ycombinator.com/item?id=28411786

Compared to the C ABIs, the Linux system call ABI is really simple and easy to understand. No way to screw it up.

The vDSO ABI should be as simple as the system call ABI. As it is right now, it pretty much forces people to use C.

Here's an article about OpenBSD's efforts https://lwn.net/Articles/806776/

The basic idea is to make it harder for remote code execution bugs to result in useful abilities. Restricting access to syscalls to libc, and using adress randomization to make it hard to find libc makes it harder to do system calls when you take over a program.

I see. That's really interesting. Looks like it is implemented by mprotecting the pages where the trusted code resides. The program's text segments are considered trusted by default so a freestanding C program that makes system calls directly should not be affected.

https://lwn.net/Articles/806863/

> For static binaries, the valid regions are the base program's text segment and the signal trampoline page.

I'm not sure but it looks like the BSD libc is some kind a special case? Surely this is not necessary? A compiler or language runtime should be able to somehow mark those segments with the appropriate permissions.

The kernel interface varies by architecture though.

Reply on news.ycombinator.com