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