Hardened Malloc - Hardened Memory Allocator

1 Like
1 Like


This is now in Whonix testers repository.

1 Like

Tested this by globally preloading it and there are a few issues (likely not with hardened_malloc itself though):

  • It’s quite slow
  • The mouse is a bit janky
  • Xorg bugs out but then fixes itself
  • The Tor Browser refuses to start

I still think we should enable this globally by default though. Just with a few exceptions + reporting any bugs uncovered upstream. Or, alternatively, we can try disabling a few options and see if it fixes anything.


Even with all of those options disabled, it’s still pretty secure.


I tried the leaner configuration example and literally all issues are fixed.

make \

I don’t even see much of a performance loss anymore. Can you test this also?

1 Like

https://www.whonix.org/wiki/Hardened_Malloc is a Debian package for “public service” for lack of better term. Changing compile time options would be weird because then it would be a fork. It would reduce security for those who are using it right now.

Though, could always stop providing that public service and call it a Kicksecure specific fork.

Or compile it twice during build if that is possible (probably is). The default, not-used by default hardened-malloc package and perhaps hardened-malloc-kicksecure - the latter could be installed to a different path and enabled by default.

1 Like

That would be the best choice. Users could use the default hardened_malloc for some applications if they want for the extra security features.




@madaidan yet another option: is there a way to blacklist the apps that run into problems when running under the standard hardened_malloc and maybe redirect them to the system default one? Can multiple mem allocators coexist on the same system?

Or maybe reserve the permissive fork for problematic programs and otherwise defer them to the more secure version (by default) as is from Micay?



Those problematic programs seem to be most things so it would make more sense to keep the permissive one as the default.


Managed to trim the config down to


with the help of Daniel.


I’ve tried to implement this. What do you think?


1 Like

I don’t want to fork any of the files shipped by upstream if not absolutely required. make isn’t something I am comfortable with long term. However, if such Makefile changes were upstreamed this were very much OK. But in this case I doubt upstream would accept a patch to introduce libhardened_malloc_kicksecure.so: $(OBJECTS) and code duplication.

What upstream might accept is configuring the resulting “end product” (for lack for better term) file name libhardened_malloc.so. I.e. could libhardened_malloc.so: $(OBJECTS) be made configurable? If not set, default to libhardened_malloc.so. If set, use that filename set from a make variable.

rm *.o

Better run make clean. More appropriate and future proof.

Here is an approach which would not need any upstream patches, which doesn’t require modifications of files shipped by upstream that should be sold.

	dh_auto_build -- libhardened_malloc.so CONFIG_NATIVE=false CC=$(CC)
	mv libhardened_malloc.so libhardened_malloc.so_original
	make clean
	mv libhardened_malloc.so libhardened_malloc.so_kicksecure


libhardened_malloc.so_original usr/lib/libhardened_malloc.so/libhardened_malloc.so
libhardened_malloc.so_kicksecure usr/lib/libhardened_malloc.so/libhardened_malloc_kicksecure.so

Would that work?


Yes, that’d be perfect.

1 Like

Could you do a new test / PR please?

Where should this be enabled? A new package - hardened-malloc-enable?

1 Like

That… Is a good question… I was thinking about how to best enable this.

Only option seems to be this:

I.e. modify /etc/ld.so.preload. Would be a bit troublesome because there is no drop-in folder at time of writing. [1] Was thinking about writing to that file from a postinst script (check if the so exists) and removing it in the prerm script. Protected by a state file write to /etc/ld.so.preload just once to allow the user to disable this.

Considered doing this in the hardened-malloc package but your question made me think that this again would destroy the “unmodified hardened-malloc package public service Debian package” since enabling hardened-malloc-kicksecure by default was probably not what the user intended / expected.

I would like to avoid the overhead of having a dedicated pacakge only doing hardened-malloc-enable.

Perhaps easiest would be to abolish the “public service” of a plain Debian unmodified hardened-malloc package and calling it a Kicksecure fork since we change compile time options and enable that one by default? Probably a small thing because I guess very few use such a geeky “public service”.

[1] related feature request: /etc/ld.so.preload.d drop-in configuration folder support

1 Like


Installation path was actually wrong. Found a fix.

Quote https://manpages.debian.org/testing/debhelper/dh_install.1.en.html

dh_install cannot rename files or directories, it can only install them with the names they already have into wherever you want in the package build tree.

However, renaming can be achieved by using dh-exec with compatibility level 9 or later. An example debian/ package .install file using dh-exec could look like:

debian/default.conf => /etc/my-package/start.conf
[Imprint] [Privacy Policy] [Cookie Policy] [Terms of Use] [E-Sign Consent] [DMCA] [Investors] [Priority Support] [Professional Support]