Comment by caspper69 | Hacker News Reader

Comment by caspper69 | Hacker News Reader

Parent Full thread

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.

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

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.

I think NT syscalls can change. https://j00ru.vexillium.org/syscalls/nt/64/

You're meant to go through ntdll.dll, but even that interface is documented as private/unstable.

You're meant to go through published interfaces, such as the ones in kernel32.dll. ntdll is an implementation detail and so are syscalls.

You're absolutely right, they can.

And they have.

But the reality is more like this: https://xkcd.com/1172/

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.

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

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.

Reply on news.ycombinator.com