Support for statically linked binaries

[artemislena]

T.: We've been thinking bout using this within containers by mounting the file from the container host's FS, but that leadsa compatibility issues, e.g. a mismatch in glibc versions between host n container systems (n just mounting over the entire FS into the container's not that trivial nor desired necessarily, especially when ur host distro doesn't follow the FHS). 's adding support for building an entirely statically linked binary possible, so this n similar use cases would be enabled?

[thestinger]

It's supported if you build libc with hardened_malloc as the malloc implementation. Not really clear what else we could do to make it easier to do.

[girlbossceo]

Maybe it'll help if I explain my usecase here too. I currently maintain hardened_malloc-rs. I made this because I would like to integrate hardened_malloc into Rust crates without relying on LD_PRELOAD and receiving all the benefits from Rust's compiler and linker optimisations which LD_PRELOAD does not provide, and be able to provide static binaries of my Rust crate with hardened_malloc in them (just like tikv-jemallocator does).

The problem I faced was that the hardened_malloc Makefile links and performs LTO automatically, generally with lld when using Clang, while rustc uses the generic ld wrapper and lld produces LLVM-IR bitcode that can't be linked with ld. Additionally I can't link a .so file. I also needed the individual objects files that I would link apart of hardened_malloc-rs's build.rs file. (https://github.com/girlbossceo/hardened_malloc-rs/issues/5)

This issue doesn't impact GCC users because the IR bitcode generated is compatible, but it's still unnecessary "double linking/LTO".

My workaround was to create a (likely misleading) CONFIG_STATIC config option for hardened_malloc here: https://github.com/girlbossceo/hardened_malloc/commit/dd52b42757d49a6b25dc0b22ce44dc1133c991c0

This simply skips linking the object files and skips LTO from hardened_malloc.

Then use those object files and CONFIG_STATIC when building hardened_malloc-rs with the "static" feature and link the .a files at Rust compile+link time, not hardened_malloc's compile+link time (yes I know all this code is terrible): https://github.com/girlbossceo/hardened_malloc-rs/blob/main/build.rs#L142-L162

And I can tell rustc to link the static archive file with

        if cfg!(feature = "light") {
            println!("cargo:rustc-link-search={}", out_dir);
            println!("cargo:rustc-link-lib=static=hardened_malloc-light");
        } else {
            println!("cargo:rustc-link-search={}", out_dir);
            println!("cargo:rustc-link-lib=static=hardened_malloc");
        }

I also had to make this small chacha.c change that LTO would optimise out otherwise I'll get a build error: https://github.com/girlbossceo/hardened_malloc/commit/67aea43e0b85207c8a7ca946e20548b52251c0f2

I could be totally approaching this the wrong way, but I was unable to figure out any other way and this is what's working right now. If this is the wrong way, do tell me a better way.

[artemislena]

T.: @thestinger Well, we don't know how one would go bout building an entire libc w a custom malloc, n whether it'd be possible LD preloading that within a container that was made w a different libc version (or entirely different libc). I understand documenting that might be outta scope for this project, but in that case, might be nice'f't linkeda appropriate third-party docs in the README.

@girlbossceo As for ur thing

Additionally, building hardened_malloc in your binary instead of relying on LD_PRELOAD'ing creates is more secure as it can be used to create position independent code (-fPIE/-fPIC) and prevents interposition of exported symbols (aka using LD_PRELOAD to drop in your malloc) with -fno-semantic-interposition. And it can benefit from optimisations by the compiler and linker that would not be otherwise available from a dynamic shared library.

Sounds like that can't be preloaded at all, then? Like, we'd specifically want a binary that can be preloaded from within a n already existing container, rather than rebuilding all our containers ourselves. Startinga wonder whether that's possible at all.

N I get Github issues're not intended for use as a support forum, but we don't know a better place for talking bout this (onea the GrapheneOS rooms on Matrix perhaps?).