2 ms·

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 ch

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.

matheusmoreira 5y ago
> 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.
- toast0 5y ago
  Here's an article about OpenBSD's efforts https://lwn.net/Articles/806776/ 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.
  - matheusmoreira 5y ago
    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/ 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.
- Joker_vD 5y ago
  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/ https://lwn.net/Articles/806776/ [1] https://news.ycombinator.com/item?id=21859612 https://news.ycombinator.com/item?id=21859612
  - matheusmoreira 5y ago
    > 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 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.

matheusmoreira 5y ago

> 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.

toast0 5y ago
Here's an article about OpenBSD's efforts https://lwn.net/Articles/806776/ 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.
- matheusmoreira 5y ago
  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/ 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.
Joker_vD 5y ago
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/ https://lwn.net/Articles/806776/ [1] https://news.ycombinator.com/item?id=21859612 https://news.ycombinator.com/item?id=21859612
- matheusmoreira 5y ago
  > 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 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.