Hardened Malloc - Hardened Memory Allocator

Package hardened-malloc is now available from Whonix testers repository. Will move to stable-proposed-updates and stable repository over time.

It installs its file to /usr/lib/libhardened_malloc.so/libhardened_malloc.so.

Package hardened-malloc will be installed by default in Whonix but not used by default for anything in Whonix (yet) since installation by default simplifies things but does not break things.


Moved to its own homepage.

And available from all Whonix repositories.


Notified upstream about the fork.

Debian packaging · Issue #89 · GrapheneOS/hardened_malloc · GitHub


man bug report: add getrandom to seccomp-bpf filter - compatibility with Hardened Malloc

1 Like

Upstream inquiry

1 Like

From Tom’s reply I understand that the attacker needs to be in a privileged position on your system to fingerprint the allocator, one similar to fingerprinting the CPU and RAM behavior. An attacker with that much power can do much more damage than merely fingerprint. This doesn’t apply to run of he mill websites anyone visits.

Fingerprint non issues aside, switching up allocators is non-trivial and requires changes to the browser code base to take full advantages of its defenses. Slapping LDPRELOAD as a prefix is not enough. The allocator used in TBB has achieved defense parity with hardened_malloc so the effort needed is not justified.

I now want to focus on firejail/apparmor consequences and having a sustainable maintenance plan with upstream.

1 Like

I didn’t reach the same conclusion.

[tor-dev] TBB Memory Allocator choice fingerprint implications starts with:

Writes early…

Fingerprinting: It is most likely possible to be creative enough to fingerprint what memory allocator is used.

Does not state what local exploitation is a prerequisite. If this matters, please quote the passages which lead to the conclusion and/or ask him to clarify this very point.


LD_PRELOAD=‘/path/to/libhardened_malloc.so’ /path/to/program will do
nothing or approximately nothing.

Reason enough to disable hardened malloc for Tor Browser when using tb_hardening=true. Will work on that.

harden_malloc definitely has more bells and whistles than mozjemalloc.
But the benefit gained by slapping in an LD_PRELOAD and calling it a
day is small to zero. Probably negative because you’ll not utilize
partitions by default.

More reason to do so.

1 Like

The torbrowser script Whonix uses to start TBB does more than just start TBB. Using hardened_malloc for the whole script may give a minimal security advantage.

I’d love to see Daniel Micay’s opinion on this too.

1 Like

It looks like what Tom said was a bunch of misinformation and a subtle attack on Daniel’s work.

Daniel Micay responded [tor-dev] TBB Memory Allocator choice fingerprint implications

It seems like the only true thing Tom said was that the allocator can’t be changed by a simple LD_PRELOAD change.

1 Like

I stand corrected. Based on new information in I conclude hardened_malloc is superior in security standpoint in every way over jemalloc (the latter is general purpose). I want to enable it by default for KVM builds, fingerprinting aside. There comes a point where security trumps fingerprinting worries.

What we need to figure out is the best way to integrate it into TBB. Daniel IIRC said that disabling jemalloc is the right way to go over using LD-PRELOAD ?

I am curious how functional Whonix would be if we switch to OpenBSD’s allocator for the rest or the system (seeing that it is widely tested against a large package selection by a OS already). Then we can enable hardened-malloc for security sensitive daemons whenever possible.

I think the misunderstanding was caused by an imprecise use of language.

That would be the first time we make changes to Tor Browser which are not related to integration into a Linux distribution (Whonix). Until now, no changes affected fingerprinting of default installation vs Tor Browser on Debian. Only environment variables were changed and add Tor Browser first startup popup to ask whether security slider should be set to safest drops (opt-in) a user.js file.

The higher Whonix’s popularity, the less fingerprinting arguments would make sense. If most Tor users were Whonix users, then Whonix could take the lead in fingerprint. For now, we’d stand out.

Already created consider using Hardened Malloc for better security in TBB (#31440) · Issues · Legacy / Trac · GitLab for it.

Speak: compile time option / require recompilation / build compiled by someone other than upstream?

1 Like


I’m not sure how stable a memory allocator designed for BSD would be on Linux.

Daniel Micay doesn’t see it as much of a problem as much more important information such as hardware details can be gotten via performance fingerprinting which TBB doensn’t fully protect against.

[tor-dev] TBB Memory Allocator choice fingerprint implications :

Performance-based fingerprinting of the browser can easily differentiate between using a different malloc implementation. That can already obtain a lot of fingerprinting information about the hardware and OS so this may not actually matter much, but it’s entirely possible.

Although, performance fingerprinting will probably not affect VMs as much as long as most Whonix users allocate the same amount of RAM and CPUs to the VM.

With the way that mailing list went, I don’t think they’d be too eager to implement it.

1 Like

If we use hardened_malloc along with AppArmor or Firejail would we need to allow access to /usr/lib/libhardened_malloc.so in the AppArmor/Firejail profile?

Can someone test if it’s needed or not?

1 Like

I wonder if this is even possible due to the recent kernel hardening. Many of the things done for kernel hardening have a performance decrease and may obfuscate the results of any performance fingerprinting.

1 Like

At this point unless outside code contrbutors add this TBB it won’t happen. The ML discussion concludes that the added benefit of it for modern exploit techniques is negligible.

1 Like