Suckless has a project to get a fully static compiled Linux environment. Unfortunately I don't know how far that have come
Dynamic linking
11–20 of 249 posts
Re: Dynamic linking
#12A better way to do this analysis would be to build a Linux distribution with everything statically linked and compare to the normal version with dynamic linking, looking at disk space used, startup time, memory used, and time to launch specific applications both cold and hot.
> A better way to do this analysis would be to build a Linux distribution with everything statically linked [..]
Here you go: Stali
https://dl.suckless.org/htmlout/sta.li/
"Stali distribution smashes assumptions about Linux"
https://www.infoworld.com/article/3048737/stali-distribution...
Re: Dynamic linking
#13What are the counter arguments?
Run htop or similar, sort by "shared memory" column and see how much more memory you'd need per process if shared linking did not exist. I think the author's using a wrong method to make a point. Dynamic linking feels out of place for most long-running server-side apps (typical SaaS workload). One can argue that in a mostly CLI-environment there's also not much benefit. But even an empty Ubuntu desktop runs ~400 proc…
That is an extremely misleading figure. Shared memory is page-aligned entire libraries dropped into RAM. Statically linking would, as the article shows, only use on average about 4% of the symbols available from the libraries, and the majority of this would not end up in RAM with your statically linked binary. And if you used a more selective approach, dynamically linking to no more than perhaps a dozen high-impact libraries and statically linking the rest, you'd get a lot of the benefits and few of the drawbacks.
Put the cold hard numbers right in front of someone's face and still the cargo cult wins out.
Re: Dynamic linking
#14Do any Linux/glibc or Linux/musl systems support static PIE binaries, yet? Without static PIE support you don't benefit from ASLR (at least not fully). This 2018 article seems like a good breakdown of the issues: https://www.leviathansecurity.com/blog/aslr-protection-for-s... OpenBSD has supported static PIE since 2015; not just supported, but all system static binaries (e.g. /bin and /sbin) are built as static PIEs,…
Most Linux/musl systems support it. On Alpine, gcc is built with `--enable-default-pie` so all static libraries can be linked into a static PIE.
On vanilla gcc (since version 8 when static PIE was upstreamed), `-static` means non-PIE static executable and there is a separate flag for `-static-pie` for static PIE. Alpine patches gcc so that `-static` and `-pie` are independent flags, so both `cc -static` and `cc -static-pie` will produce a static PIE.
Re: Dynamic linking
#15>Do your installed programs share dynamic libraries?
>Findings: not really
>Over half of your libraries are used by fewer than 0.1% of your executables.
Findings: Yes, lots, but mostly the most common ones. Dynamically linking against something in the long tail is pretty pointless though.
Re: Dynamic linking
#16A better way to do this analysis would be to build a Linux distribution with everything statically linked and compare to the normal version with dynamic linking, looking at disk space used, startup time, memory used, and time to launch specific applications both cold and hot.
> A better way to do this analysis would be to build a Linux distribution with everything statically linked [..] Here you go: Stali https://dl.suckless.org/htmlout/sta.li/ "Stali distribution smashes assumptions about Linux" https://www.infoworld.com/article/3048737/stali-distribution...
For a useful comparison you need the static and dynamic distributions to be otherwise the same, i.e. you want to pick a mainstream distribution and build it from scratch with both static and dynamic linking and compare.
Re: Dynamic linking
#17What are the counter arguments?
Run htop or similar, sort by "shared memory" column and see how much more memory you'd need per process if shared linking did not exist. I think the author's using a wrong method to make a point. Dynamic linking feels out of place for most long-running server-side apps (typical SaaS workload). One can argue that in a mostly CLI-environment there's also not much benefit. But even an empty Ubuntu desktop runs ~400 proc…
Go executables are statically linked. It makes deployment a breeze.
I think you overestimate how much saving you get from dynamically linking libc. Each executable uses only a small portion of libc, so the average savings is going to be in the handful of kilobytes per executable.
Re: Dynamic linking
#18Do any Linux/glibc or Linux/musl systems support static PIE binaries, yet? Without static PIE support you don't benefit from ASLR (at least not fully). This 2018 article seems like a good breakdown of the issues: https://www.leviathansecurity.com/blog/aslr-protection-for-s... OpenBSD has supported static PIE since 2015; not just supported, but all system static binaries (e.g. /bin and /sbin) are built as static PIEs,…
I imagine there's some way to, because the kernel is able to apply ASLR to the dynamic linker itself.
It's not a matter of possible, but whether the work has been done throughout the toolchain and runtime stacks.
When OpenBSD implemented static PIE, -static and -pie, the literal options and the code generation aspects more generally, were still mutually exclusive in GCC and clang. GCC required patching to enable both static linking and PIE generation. In fact, my local GCC 9.3 man page still says that -static overrides -pie; to build static PIE seems to require the special option -static-pie, in addition to -fPIE/-fPIC when building the object code. But it's not enough for the compiler and compile time linker to support it. libc and libstdc++/libc++ also need support, both internally as well as in the built libraries. And I think libdl might need support if you want dlopen to work from a static PIE binary. Likewise for libpthread. Supporting static PIE requires the cooperation of many moving parts. And that's just to support it. Making it easy, let alone the default behavior, so that it doesn't require many carefully coordinated, obscure flags without the risk of any misstep silently disabling some exploit mitigation, is yet another story.
It can be done. It should be done. But to what extent has it been done? I'm not sure, though some quick Googling suggests GCC and clang are mostly there, at least in terms of nominal support (which, again, is distinct from fully supporting all the same mitigation measures). glibc seems to have gotten some support (e.g. --enable-static-pie in glibc's build), though I'm not sure whether it's available in distros. And I would guess that musl libc support is pretty far along, and presumably more mature than glibc's given that Rich Felker started experimenting with static PIE several years ago, shortly after OpenBSD did their work. See https://www.openwall.com/lists/musl/2015/06/01/12
Re: Dynamic linking
#19>Do your installed programs share dynamic libraries? >Findings: not really >Over half of your libraries are used by fewer than 0.1% of your executables. Findings: Yes, lots, but mostly the most common ones. Dynamically linking against something in the long tail is pretty pointless though.
> Dynamically linking against something in the long tail is pretty pointless though.
I disagree. Dynamic linking, in the context of an OS which offers a curated list of packages in the form of an official package repository, means that a specialized third party is able to maintain a subcomponent of your system.
This means you and me and countless others are able to reap the benefit of bugfixes and security fixes provided by a third-party without being actively engaged in the process.
In the context of an OS where the DLL hell problem hasn't been addressed and all software packages are forced to ship all their libraries that are shared with no one at all, indeed its pretty pointless.
Re: Dynamic linking
#20Suckless has a project to get a fully static compiled Linux environment. Unfortunately I don't know how far that have come
I don't think stali has seen any activity in several years.
As far as I know, the only completely statically linked Linux distribution that is actively developed is my own project (inspired by stali), oasis: https://github.com/oasislinux/oasis