3 ms·

Not related. The blog post is a mini-rant complaining about how other people are complaining about having to link "all of libc" on BSD when their standard libr

Not related. The blog post is a mini-rant complaining about how other people are complaining about having to link "all of libc" on BSD when their standard libraries are not based on libc (libc is the interface to the kernel on BSD). He's talking about static linking. Honestly, I'm not terribly sure I get it, as almost all "other languages" link to libc in some way on most OSes, and don't call native kernel interfaces directly at all. But maybe it's more common than I think. Famously, Go went this route and it caused them no end of consternation with their FFI, and they've gone back in the other direction of linking with libc directly. In your case, reordering has to do with ASLR (address randomization) in dynamic libraries. OpenBSD takes ASLR a step further and so not only randomizes the libraries themselves, but the archives inside the library and the functions themselves- they call it KARL. That's what it's doing when you see that message.

chasil 2y ago
Right, but does that mean that /bin/ls changes at every boot, because some of what it took from libc is dynamic?
- caspper69 2y ago
  The article states that /bin/ls is statically linked. That means that the parts it uses from libc have long-since been taken and merged directly into the ls binary. So this randomization has no effect. Even if ls were dynamically linked, the ls binary itself wouldn't change at every boot; instead its import/jump table, generated dynamically by ld.so as part of the OS's executable loading process, would simply point to different (and random) offsets within libc. It would have a different in-memory representation after each boot, but its on-disk representation would remain the same.
kazinator 2y ago
On Linux, your language run-time can call into the kernel directly with itsown syscall assembly language stubs. The kernel interface is something public and stable, independently of the C library (of which there are several available, incidentally: glibc, uClibc, musl, ...).
- caspper69 2y ago
  Right, I understand that. You can do the same on Windows too. My point was that most languages' runtimes don't do that, not that they can't do that.
  - andrewf 2y ago
    I think NT syscalls can change. https://j00ru.vexillium.org/syscalls/nt/64/ https://j00ru.vexillium.org/syscalls/nt/64/ You're meant to go through ntdll.dll, but even that interface is documented as private/unstable.
    - caspper69 2y ago
      You're absolutely right, they can. And they have. But the reality is more like this: https://xkcd.com/1172/ https://xkcd.com/1172/
    - immibis 2y ago
      You're meant to go through published interfaces, such as the ones in kernel32.dll. ntdll is an implementation detail and so are syscalls.
  - kazinator 2y ago
    Because then they would face additional portability hurdles that they can avoid by targeting POSIX. Even decent porting to Windows is possible (speaking of which) via POSIX.

chasil 2y ago

Right, but does that mean that /bin/ls changes at every boot, because some of what it took from libc is dynamic?

caspper69 2y ago
The article states that /bin/ls is statically linked. That means that the parts it uses from libc have long-since been taken and merged directly into the ls binary. So this randomization has no effect. Even if ls were dynamically linked, the ls binary itself wouldn't change at every boot; instead its import/jump table, generated dynamically by ld.so as part of the OS's executable loading process, would simply point to different (and random) offsets within libc. It would have a different in-memory representation after each boot, but its on-disk representation would remain the same.

kazinator 2y ago

On Linux, your language run-time can call into the kernel directly with itsown syscall assembly language stubs. The kernel interface is something public and stable, independently of the C library (of which there are several available, incidentally: glibc, uClibc, musl, ...).

caspper69 2y ago
Right, I understand that. You can do the same on Windows too. My point was that most languages' runtimes don't do that, not that they can't do that.
- andrewf 2y ago
  I think NT syscalls can change. https://j00ru.vexillium.org/syscalls/nt/64/ https://j00ru.vexillium.org/syscalls/nt/64/ You're meant to go through ntdll.dll, but even that interface is documented as private/unstable.
  - caspper69 2y ago
    You're absolutely right, they can. And they have. But the reality is more like this: https://xkcd.com/1172/ https://xkcd.com/1172/
  - immibis 2y ago
    You're meant to go through published interfaces, such as the ones in kernel32.dll. ntdll is an implementation detail and so are syscalls.
- kazinator 2y ago
  Because then they would face additional portability hurdles that they can avoid by targeting POSIX. Even decent porting to Windows is possible (speaking of which) via POSIX.