Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Sta.li: Static Linux

sta.li

Post reply on HN
Print view View original

41–50 of 99 posts

Re: Sta.li: Static Linux

#41

Post by ksk »

kev009 wrote: post #38

In case it's not obvious: if you static link to a library, say libpng, and a vuln hits, every binary that linked to libpng potentially needs to be rebuilt and distributed. If the OS has rigid dependency tracking (maybe source distros like Gentoo, or a cryptographically tracked binary distribution like freebsd-update), maybe you can live with that. So there's some trade off of "dll hell" for binary hell, and perhaps s…

There are already ways to mitigate that. One example would be to use mandatory access control to 'host' the library in a separate process which is stripped off of all unnecessary rights/privileges.

Re: Sta.li: Static Linux

#42

Post by prewett »

davidp wrote: post #31
clord wrote: post #26

Earlier quoted context omitted.

On top of what others have said, it takes some time to dynamically load a library into an address space. There are tables that may need to be walked and updated with correct pointers. For large libraries, this can be quite measurable. A statically linked executable will be memory-mapped and then brought in lazily as the program runs. And then if executed again, everything is mapped and loaded, so there is zero delay.…

> it takes some time to dynamically load a library into an address space. There are tables that may need to be walked and updated with correct pointers True, but I'd expect that to be dwarfed by the I/O time required to load even a single 4k page from disk, vs. keeping one copy of a big dynamic library like glibc loaded for the whole system, with fixups done per-process. Good points about ASLR and static-linking freq…

A lot of those pages will already be in the file cache (assuming his use case of small utilities running frequently). Anyway, it should be easy to test: since glibc will always be in memory, any differences in timing between the static and dynamic version should be those alleged loading costs.

Re: Sta.li: Static Linux

#43

Post by exDM69 »

spc476 wrote: post #28
cgh wrote: post #17

Earlier quoted context omitted.

Static linking doesn't necessarily link the entire library, unless the entire thing compiles to a single .o file. Linkers are smart enough to only link in the object files needed by the program. So assuming you are only linking in well-designed libraries, I guess it's possible that statically-linked software will be smaller since it will leave out the stuff you aren't using.

I recently played around with this, taking a rather small project (around 15,000 lines of code), putting it all into a single file and compiling. It did produce a smaller executable, but the real gain was in making every function static (since it's all in a single file). Doing that, a total of 41 functions were eliminated (either inlined or not used at all). Was it worth the effort? Eh. But it was instructive and I'd…

Some popular software like SQLite combine all their sources into one big source file called Amalgamation and then compile that. Their benchmarks show modest but not negligible performance gain.

There's a lot of work going on in link time optimization at the moment, both in LLVM and GCC. It's not quite ready for prime time, it still takes more than a small change in your Makefile to deploy it (e.g. dealing with linkers etc).

With LLVM toolchain you can compile C code (or other high level code) into LLVM IR, link the IR files together and run that through the optimizer.

You will notice that modern optimizers will want to inline everything if possible and a lot of functions will be missing from the resulting binary. Boundaries of object files are perhaps the biggest obstacle in optimization today.

Re: Sta.li: Static Linux

#44

Post by ploxiln »

vinkelhake wrote: post #9

On binary sizes: > Linking a stripped hello world program with glibc results in 600kb. Linking it with uclibc in about 7kb. That's nice for uclibc, but we're typically linking dynamically. The comparison should be between dynamically and statically linked binaries. A stripped and dynamically linked hello world results in a 6kb program on my machine (glibc). There's also a lot of handwaving on memory usage in the FAQ.

Yeah - so your stripped and dynamically linked executable is just about as large as a statically built one... and yours still has to link glibc.

I can build busybox (a multi-call all-in-one executable, use symlinks to refer to the binary with the name of a tool and it acts like that tool), with init and bourne shell and the minimal set of command-line tools (coreutils remakes and util-linux remakes) into a 600KiB executable statically linked with uclibc. Combined with a linux kernel, I can boot with it. Meanwhile, my glibc is 2MiB.

Modern computers are really amazing. And it's also amazing that the understandable trend of letting software get bigger and slower as long as it doesn't really cause problems on current hardware has resulted in such astounding (though mostly harmless) waste.

All that said, these stali project pages have existed for years, and there's nothing interesting to show for it. Not that many people really buy into this thing (including me).

Re: Sta.li: Static Linux

#47

Post by prewett »

Building Gentoo with USE=static might be a good way to experiment without have to build an entire new distribution. Try one with the flag, one without, do the same operations in each and watch the memory usage and time to completion.

Re: Sta.li: Static Linux

#48

Post by weland »

mcot2 wrote: post #11
davidp wrote: post #10

I'm puzzled by the idea of a system being leaner/faster with n copies of a library in physical RAM rather than 1 copy mapped via VMM into whatever process wants it. IIRC this was the main point of shared libraries, not pluggability or changing code during runtime. Am I missing something?

Maybe if we didn't have gigabytes of RAM these days. I quite like the idea of static linking. It makes software packaging and distribution very very easy and it has some security benefits. Go's build system is a good example of this. This project seems to be dead.

I have mixed feelings about the security gains.

On one hand, you eliminate one attack vector since you take ldd out of the equation. On the other hand, you depend on packagers who distribute their programs to rebuild and relink them every time a security issue creeps up a library they link with. I'm not sure I like that, and I don't have the free time I had in high school when compiling everything by hand seemed really fucking cool.

Re: Sta.li: Static Linux

#50

Post by benjamincburns »

prewett wrote: post #47

Building Gentoo with USE=static might be a good way to experiment without have to build an entire new distribution. Try one with the flag, one without, do the same operations in each and watch the memory usage and time to completion.

Took the words right out of my mouth. Though I think to do this well you'd need to go old school and do a fully bootstrapped (formerly "stage 1") install.
Post reply on HN