@GrahamcOfBorg test hardened

Neat 😁 - you might like to consider making this a setting that can generally cope with "alternative malloc implementations" rather than just a boolean - I'm looking at one or two more "hardened mallocs" which I'm considering adding.

My preference would be for the module to simply select "the best one", but then I don't know enough about the various hardened mallocs & their tradeoffs.

A general module could expose an option that lets you specify the path to the .so file or simply choose from one or more pre-defined alternatives ("graphene", "jemalloc", etc). Makes some sense to me, though there is decent potential for misconfiguration ...

I'll try to hack up something to better compare.

Something like https://github.com/joachifm/nixpkgs/blob/feat/configurable-malloc/nixos/modules/config/malloc.nix is what I had in mind ...

That looks great - there's of course this slight ... incongruity ... with the traditional way things work in nix-land - to minimize runtime link resolution. But these mallocs don't universally support linking directly into a libc and it's not practical to wrapProgram every binary in the system, so I can't think of anything better than a global LD_PRELOAD.

Yes, it's pretty awful ...

Besides wrappers, another alternative is to use /etc/ld-nix.so.preload but that is last in the preload order.

I feel like it should be possible to patch ld.so somehow specifically to support mandatory overrides for things like hardened allocators but that seems like a more ambitious undertaking & not sure if enough people care about this to make it worth it.

I'll probably polish the malloc module & submit a PR for it soonish.

Well, when it comes to "enough people caring" I'm always reminded how far behind the likes of OpenBSD we all are and how much we need to up our game.