3 ms·

The issue here is that you shouldn't need to interface with C, unless you need to talk to some C Code. You absolutely shouldn't have to interface with C to talk

The issue here is that you shouldn't need to interface with C, unless you need to talk to some C Code. You absolutely shouldn't have to interface with C to talk to the kernel. I come at this from a Linux perspective, but to me the user/kernel interface (sys calls etc.) should be the well defined abstraction boundary. The C library is a useful api making that easy to use, but to dictate that people can only make sys calls through C is silly and ends up with these sort of problems.

matheusmoreira 7y ago
This happens due to POSIX. Nothing stops people from using direct system calls but they would rather use a C library for portability reasons. I'd even say the Linux system call interface is better than the POSIX one. Well documented, no errno. I wrote a liblinux in C and Rust and it's been useful for accessing newer system calls with no libc stubs. The more subtle problem: standard C libraries are incompatible with direct system calls. They maintain a lot of global state which will be invalidated if the program calls the kernel directly. For example, clone() cannot be used with glibc. The ideal solution is to start from scratch and build a new user space without using C at all.
amluto 7y ago
There is quite a bit of variation here. Linux and, AIUI, quite a few microkernels, have a defined ABI at the user/kernel boundary. BIOS, a bunch of hypervisors, and some RISC-V M-mode interfaces are similar, albeit with “user” and “kernel” replaced with other execution modes. OpenBSD and, very notably, Windows instead have a defined library interface. Windows has somewhat stable “system calls”, but only through NTDLL.dll. The real stable interface is kernel32, etc. There are arguments in favor of both approaches. One significant, if rarely appreciated benefit of the user/kernel approach is that it enables user programs that don’t use the C ABI at all. Go on Linux is like this, and Go and the vDSO have interoperability issues because the vDSO is a bit FFI-ish in Go, and Go’s FFI is not very fast.
- the_why_of_y 7y ago
  A stable syscall ABI is a Linux peculiarity and was never a part of the UNIX tradition. Here's a talk where Bryan Cantrill describes the tightly coupled Solaris kernel/libc combination as a "welded unit", and mocks the Linux "libc ecosystem" and the complexity of ENOSYS handling in glibc. https://www.youtube.com/watch?v=TrfD3pC0VSs#t=29m10 https://www.youtube.com/watch?v=TrfD3pC0VSs#t=29m10
  - amluto 7y ago
    Mock it all you like. Old static binaries, old containers, and old chroots continue to work on new kernels. This is a big deal.
wsxcde 7y ago
There's no problem with directly calling sycalls from OpenBSD from golang or C or whatever else. The issue here is that OpenBSD is adding a new security feature where code addresses that call syscalls must be whitelisted at link time. golang could just create their own syscall interface and linker scripts appropriately whitelisting these locations and this problem wouldn't exist.

matheusmoreira 7y ago

This happens due to POSIX. Nothing stops people from using direct system calls but they would rather use a C library for portability reasons. I'd even say the Linux system call interface is better than the POSIX one. Well documented, no errno. I wrote a liblinux in C and Rust and it's been useful for accessing newer system calls with no libc stubs. The more subtle problem: standard C libraries are incompatible with direct system calls. They maintain a lot of global state which will be invalidated if the program calls the kernel directly. For example, clone() cannot be used with glibc. The ideal solution is to start from scratch and build a new user space without using C at all.

amluto 7y ago

There is quite a bit of variation here. Linux and, AIUI, quite a few microkernels, have a defined ABI at the user/kernel boundary. BIOS, a bunch of hypervisors, and some RISC-V M-mode interfaces are similar, albeit with “user” and “kernel” replaced with other execution modes. OpenBSD and, very notably, Windows instead have a defined library interface. Windows has somewhat stable “system calls”, but only through NTDLL.dll. The real stable interface is kernel32, etc. There are arguments in favor of both approaches. One significant, if rarely appreciated benefit of the user/kernel approach is that it enables user programs that don’t use the C ABI at all. Go on Linux is like this, and Go and the vDSO have interoperability issues because the vDSO is a bit FFI-ish in Go, and Go’s FFI is not very fast.

the_why_of_y 7y ago
A stable syscall ABI is a Linux peculiarity and was never a part of the UNIX tradition. Here's a talk where Bryan Cantrill describes the tightly coupled Solaris kernel/libc combination as a "welded unit", and mocks the Linux "libc ecosystem" and the complexity of ENOSYS handling in glibc. https://www.youtube.com/watch?v=TrfD3pC0VSs#t=29m10 https://www.youtube.com/watch?v=TrfD3pC0VSs#t=29m10
- amluto 7y ago
  Mock it all you like. Old static binaries, old containers, and old chroots continue to work on new kernels. This is a big deal.

wsxcde 7y ago

There's no problem with directly calling sycalls from OpenBSD from golang or C or whatever else. The issue here is that OpenBSD is adding a new security feature where code addresses that call syscalls must be whitelisted at link time. golang could just create their own syscall interface and linker scripts appropriately whitelisting these locations and this problem wouldn't exist.