alt Hacker NewsI’m aware of this but I really don’t the benefits of this approach; It causes issues in eg openbsd where you can only call syscalls from libc, and it seems like they’re trying to outsmart the os developers and I just don’t see an advantage.
Is it faster? More stable?
Replies
> I just don’t see an advantage.
You don’t have to deal with C ABI requirements with respect to stack, or registers management. You also don’t need to do dynamic linking.
On the other hand all of that comes back to bone you if you’re trying to benefit from vDSO without going through a libc.
GNU aren't the OS developers of the Linux kernel. Think of the Go standard library on Linux as another libc-level library. On the BSDs there is a single libc that's part of the OS, on Linux there are several options for libc.
> It causes issues in eg openbsd where you can only call syscalls from libc
OpenBSD allows making syscalls from static binaries as well. If Go binaries are static, it shouldn't cause any problems.
There are several advantages to using kernel syscalls directly:
1. No overhead from libc; minimizes syscall cost
2. No dependency on libc and C language ABI/toolchains
3. Reduced attack surface. libc can and does have bugs and potentially ROP or Spectre gadgets.
4. Bootstrapping other languages, e.g. Virgil