3 ms·

When I boot OpenBSD, I see: reordering: ld.so libc libcrypto sshd. How does that play into this?

• caspper69 2y ago
  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.
• wahern 2y ago
  Not directly related, but note what is mentioned in the post about the purpose of individual object files for each function. What might be considered an anachronism is being leveraged for improved security. What's happening (IIRC) with the reordering is that all those otherwise dynamically linked binaries (sshd is a PIE binary) are being themselves relinked from scratch (OpenBSD ships with the .o files), but shuffling the order of .o files passed to the linker. This effectively enhances ASLR. The way ASLR normally works is that each binary (program or shared library) is loaded into a random base address, but all the functions defined in each binary are fixed relative to each other. In stock installations libc's fopen is at a fixed offset from libc's snprintf, for example, and this will be true for every program loading libc.so. In the above, libc.so is relinked with a randomized ordering to the .o object files. The result is that relative offsets for libc functions on your individual system will be different from every other system, including from your previous boot, hopefully making exploits (e.g. utilizing ROP chains) more difficult. More modern projects like libcrypto and sshd tend to group related functions into the same .o file, so all the functions in each .o will still have a fixed offset from each other, but they still have quite alot of individual .o files to shuffle. Note that OpenBSD does the same thing for the kernel.