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

> 1. No overhead from libc; minimizes syscall cost

The few nanoseconds of a straight function call are absolutely irrelevant vs the 10s of microseconds of a syscall cost and you lose out on any of the optimizations a libc has that you might not or didn't think about (like memoization of getpid() ) and you need to take on keeping up with syscall evolution / best practices which a libc generally has a good handle on.

> No dependency on libc and C language ABI/toolchains

This obviously doesn't apply to a C syscall header, though, such as the case in OP :)

A syscall can be way less than 10us. Especially if it is not doing I/O.

But a kernel mode switch is definitely more expensive than a trivial (likely cached) jump instruction.

> you lose out on any of the optimizations a libc has that you might not or didn't think about (like memoization of getpid() )

Not much of a big deal. These "optimizations" caused enough bugs that they actually got reverted.

https://www.man7.org/linux/man-pages/man2/getpid.2.html

  Because of the aforementioned problems, since glibc 2.25,
  the PID cache is removed: calls to getpid() always invoke
  the actual system call, rather than returning a cached value.

Get rid of libc and you gain the ability to have zero global state in exchange. Freestanding C actually makes sense and is a very fun language to program in. No legacy nonsense to worry about. Even errno is gone.

> Get rid of libc and you gain the ability to have zero global state in exchange.

No you don't, you still have the global state the kernel is maintaining on your behalf. Open FDs, memory mappings, process & thread scheduling states, limits, the command line arguments, environment variables, etc... There's a shitload of global state in /proc/self/

Also the external connections to the process (eg, stdin/out/err) are still inherently global, regardless of however your runtime is pretending to treat them.

And it's not like you even managed to reduce duplicated state since every memory allocator is going to still track what regions it received from the kernel and recycle those.

> Freestanding C actually makes sense [..] No legacy nonsense to worry about

Except for, you know, the entire language :p

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

> You also don’t need to do dynamic linking.

This is a big one. Linking against libc on many platforms also means making your binaries relocatable. It's a lot of unnecessary, incidental complexity.

It also means giving up ASLR, though.

You can still randomize heap allocations (but not with as much entropy), as usually the heap segment is quite large. But you don't get randomization of, e.g. the code.

ASLR is a weak defense. It's akin to randomizing which of the kitchen drawers you'll put your jewelry in. Not the same level of security as say, a locked safe.

Attacks are increasingly sophisticated, composed of multiple exploits in a chain, one of which is some form of ASLR bypass. It's usually one of the easiest links in the chain.

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

At least the vDSO functions really don't need much in the way of stack space: generally there's nothing much there but clock_gettime() and gettimeofday(), which just read some values from the vvar area.

The bigger pain, of course, is actually looking up the symbols in the vDSO, which takes at least a minimal ELF parser.

The kernel also provides a minimal vdso elf parser:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...

> At least the vDSO functions really don't need much in the way of stack space: generally there's nothing much there but clock_gettime() and gettimeofday(), which just read some values from the vvar area.

And yet that’s exactly one of the things Go fucked up in the past: https://marcan.st/2017/12/debugging-an-evil-go-runtime-bug/

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

> OpenBSD allows making syscalls from static binaries as well.

Do you have a source for this? My Google searches and personal recollections say that OpenBSD does not have a stable syscall ABI in the way that Linux does and the proper/supported way to make syscalls on OpenBSD is through dynamically linked libc; statically linking libc, or invoking the syscall mechanism it uses directly, results in binaries that can be broken on future OpenBSD versions.

> > OpenBSD allows making syscalls from static binaries as well.

> Do you have a source for this?

One article from 2019 about this can be found at https://lwn.net/Articles/806776/ (later updates https://lwn.net/Articles/949078/ and https://lwn.net/Articles/959562/). Yes, it does not have a stable system call ABI, but as long as your program was statically compiled with the libc from the same OpenBSD release, AFAIK it should work.

I upvoted for the great links, but I still don't think a static binary that will break in the future is meeting the expectations many have when static linking.

Yeah. Do you have any information as to how/when the OpenBSD system call ABI has changed recently? I wouldn't expect that to happen very often.

From 2019: https://lwn.net/Articles/806776/

In particular, from Theo de Raadt himself:

> we here at OpenBSD are the kings of ABI-instability

> Program to the API rather than the ABI. When we see benefits, we change the ABI more often than the API.

> I have altered the ABI. Pray I do not alter it further.

The term ABI here though is a little imprecise. I believe it just refers to the syscall ABI. So, it should be possible to make an "almost static" binary by statically linking everything except libc, and that binary should continue to work in future versions of OpenBSD.

Go recently got run through the wringer to remove syscalls (and various Go ports are probably still broken) due to pinsyscalls.

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.