search

GrapheneOS / hardened_malloc

Hardened allocator designed for modern systems. It has integration into Android's Bionic libc and can be used externally with musl and glibc as a dynamic library for use on other Linux-based platforms. It will gain more portability / integration over time.
https://grapheneos.org/
MIT License
1.29k stars 96 forks source link

Bug: Floorp (a firefox derivateive) segfaults #244

Closed Mikilio closed 1 month ago

Mikilio commented 1 month ago

I changed the system-wide allocator to the light version of this, and floorp would crash with a segfault. To be specific, I use NixOS, and it sets libhardened_malloc-light.so into the LD_PATH. I don't really know how to go about debugging this, but I'm willing to provide any information requested.

thestinger commented 1 month ago

glibc doesn't have perfect support for replacing the allocator via preloading a library and some applications have issues with it too. It's not really the most robust way to use hardened_malloc which is building it into libc as either the only malloc implementation or one of multiple as we do in GrapheneOS so we can support a toggle to use the standard one for compatibility. There's likely nothing we can do about this, you just need to exclude Firefox and derivatives of it since they override the system allocator themselves and it doesn't play well having it happen in layers.

Mikilio commented 1 month ago

Oh, so that's how it was done in GrapheneOS! Well, my question has been answered and I will close this issue. However, if hardened_malloc should ever be used as a full replacement, maybe there should be a pinned tacking issue for that? What do you think?

thestinger commented 1 month ago

Oh, so that's how it was done in GrapheneOS! Well, my question has been answered and I will close this issue. However, if hardened_malloc should ever be used as a full replacement, maybe there should be a pinned tacking issue for that? What do you think?

It can be integrated into libc with what we have published. In GrapheneOS, we build it as a static library and link that into libc which is also what they do for the standard allocator. In Android, the libc makes a read-only function pointer table for dispatching to malloc and it can choose an implementation at startup. We just added hardened_malloc as a default implementation. That's the use case for having the function prefixes like h_malloc so that it can live alongside another malloc and libc chooses the one to use at startup. It's standard Android functionality that's done in a secure way and we just reused it.