3 ms·

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

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

titzer 2y ago
> 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.
- rcxdude 2y ago
  It also means giving up ASLR, though.
  - titzer 2y ago
    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.
LegionMammal978 2y ago
> 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.
- t-8ch 2y ago
  The kernel also provides a minimal vdso elf parser: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tools/testing/selftests/vDSO/parse_vdso.c https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
- masklinn 2y ago
  > 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/ https://marcan.st/2017/12/debugging-an-evil-go-runtime-bug/

titzer 2y ago

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

rcxdude 2y ago
It also means giving up ASLR, though.
- titzer 2y ago
  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.

LegionMammal978 2y ago

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

t-8ch 2y ago
The kernel also provides a minimal vdso elf parser: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tools/testing/selftests/vDSO/parse_vdso.c https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
masklinn 2y ago
> 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/ https://marcan.st/2017/12/debugging-an-evil-go-runtime-bug/