You don't link all of Libc

https://flak.tedunangst.com/post/you-dont-link-all-of-libc

by ingve • 1 year ago

30 26 1 year ago

flak.tedunangst.com

chasil2• 1 year ago

When I boot OpenBSD, I see:

  reordering: ld.so libc libcrypto sshd.

How does that play into this?

caspper695• 1 year 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.

chasil2• 1 year ago

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

kazinator6• 1 year 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, ...).

wahern• 1 year 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.

rcxdude• 1 year ago

You can do better than working at the object file level. With --gc-sections and --ffunction-sections, the linker can include only the relevant functions into your binary (whether your libc tries to minimise internal dependencies is another question)

Neywiny• 1 year ago

I think even better than functions it can optimize out data sections too. For example if I declare a huge array and don't use it, it doesn't show up in the binary. Not always true but the are times it is.

kazinator6• 1 year ago

If you use dynamic linking, you will get all of libc mapped into your address space. It won't all be faulted in; just the parts you call. The parts you fault in should point to the same physical frame of memory that other processes have faulted in that have also called the same part of the library. That's why it's a "shared library".

alsoforgotmypwd• 1 year ago

Yeap. I roll my eyes at the people who want to static link everything and think they're somehow better or purer when they're just wasting RAM for nothing.

ericye16• 1 year ago

Static linker supporter here, not to start a flame war but I like static linking because it means I don't have to worry about version mismatches of shared libraries between what I ship and what the user gets.

kazinator6• 1 year ago

It's not for nothing. Function calls into shared libraries are pretty disgusting.

adrian_b• 1 year ago

Static linking does not have to waste any RAM by duplicating code, even if it is frequently implemented in this way.

It is possible and not complicated to implement static linking in a way where the executable file retains the metadata about the component object files and also the OS retains some information about the object files that are already loaded in memory as parts of other executables.

In this case, when loading an executable, the component objects that are already present in memory can be omitted and the references to them in the executable can be adjusted.

While this is not done in the more popular operating systems, due to their preference for the more inefficient dynamic linking, the alternative is still possible.

Moreover, it is impossible to say in general which of static linking and dynamic linking wastes more memory. Static linking will have multiple copies of some code, while dynamic linking will have a lot of unused unreachable code, which is superfluous. Moreover, dynamic linking also has some execution time overhead.

In practice, with the typical bloated dynamic libraries that are available, I have seen much more memory wasted by dynamic linking than by static linking.

When only static linking is used, there is rarely much code duplication besides a small subset of the standard C library, which includes things like the wrappers for system calls and the functions for formatted I/O.

Therefore most of the benefit in reducing memory use from dynamic linking would be achieved with a single dynamic library, which should contain only a subset of libc.

up2isomorphism• 1 year ago

Then your eye will keep rolling when all people asking for a “docker image ” for any existing software.

kazinator6• 1 year ago

With the GNU linker, you would have to go out of your way to link all of a library, like:

  ld ... --whole-archive libwhatever.a --no-whole-archive

Into the 1990s, it was still a big deal whether a linker could eliminate individual unused functions rather than just remove unused object files. I recall this ability is called function linking.

In GCC they wanted function linking for the libgcc.a functions that provide run-time support, like numeric functions (e.g. division) needed by some generated code to make up for what the machine's instruction set does not provide.

GCC's build process simulated (maybe still does?) function linking for libgcc.a by using the preprocessor to compile the file with these routines multiple times, separating the output into multiple .o files containing just one function.

These days we have a libgcc as a shared library.

You don't link all of Libc

Related Stories