4 ms·
This is incorrect. On most platforms, the libc is part of the operating system, and the libc API is the supported system call interface; user programs aren't al
by twic 4y ago
This is incorrect. On most platforms, the libc is part of the operating system, and the libc API is the supported system call interface; user programs aren't allowed to make system calls directly to the kernel, any more than they're allowed to jump directly into the middle of kernel routines.
As described elsewhere in this thread, that is the policy of MacOS X and Windows.
It is also a policy which OpenBSD is moving towards:
https://lwn.net/Articles/806863/ https://lwn.net/Articles/806863/
According to the Go devs, this is also the policy on Solaris-family OSs (Go uses libc there):
https://github.com/golang/go/issues/24357#issuecomment-373007875 https://github.com/golang/go/issues/24357#issuecomment-37300...
AFAIK, it is only Linux which explicitly supports the kernel system call interface, and so where alternative libcs are possible.
- nibbleshifter 4y ago> AFAIK, it is only Linux which explicitly supports the kernel system call interface, and so where alternative libcs are possible. You can do this on Windows. The syscall numbers change sometimes. I use it to evade EDR hooks :)
- bogomipz 4y ago>"AFAIK, it is only Linux which explicitly supports the kernel system call interface.: Could you elaborate on this? Specifically I'm not understanding what exactly is "explicit" with regards system calls on Linux compared to other OSes.
- nibbleshifter 4y agoI think by this they mean the policy of the Linux kernel "never breaking user land". Libc is seen as user land by the Linux kernel, it provides an API for programs to abstract them away from syscalls. Libc dies syscalls for programs. By "never breaking userland", Linux promises to never break libc by never changing syscall numbers/args/types - new syscalls are added in ways that don't break older syscalls. Other platforms don't make this explicit promise and reserve the right to shuffle syscalls around, change them, remove them, etc as desired - making maintaining a libc for them a pain in the ass, and programmers are told to only use the libc as syscalls don't come with guarantees. You can (and I often do) program on windows using only syscalls, but your program tends to need rebuilding across major versions as the syscall interface isn't stable. Fuck me typing that on a phone was painful.
- bogomipz 4y agoAh ok, now the explicit vs other OSes "implicit" guarantees makes sense to me. I had no idea other OSes changed their system call numbers from time to time. Thanks for your detailed response!