Hardened Malloc - Hardened Memory Allocator

  • add configuration variant system with two standard recommended configurations: default for an aggressive security-focused configuration and light for a more balanced configuration disabling a subset of the optional security features for better performance (comparable to glibc malloc without the thread cache) and much lower memory usage while still providing most of the security properties (details in README)

hardened_malloc/README.md at main · GrapheneOS/hardened_malloc · GitHub

The configuration system supports a configuration template system with two standard presets: the default configuration (config/default.mk) and a light configuration (config/light.mk). Packagers are strongly encouraged to ship both the standard default and light configuration. You can choose the configuration to build using make VARIANT=light where make VARIANT=default is the same as make. Non-default configuration templates will build a library with the suffix -variant such as libhardened_malloc-light.so and will use an out-variant directory instead of out for the build.

Package hardened-malloc-kicksecure-enable was renamed to hardened-malloc-light-enable.

All renamed from Hardened Malloc Kicksecure to Hardened Malloc Light.

Some more commits for the legacy package migration. That was difficult.

Error message during upgrading cannot be avoided without unreasonable development effort.

ERROR: ld.so: object ‘/usr/lib/libhardened_malloc.so/libhardened_malloc_kicksecure.so’ from /etc/ld.so.preload cannot be preloaded (cannot open shared object file): ignored.

Package hardened-malloc-kicksecure-enable can be safely removed after upgrade.

Now available from Whonix testers repository.

Now available from Whonix testers repository.

1 Like
1 Like

Debian Host:

Debian stable with default/full HM = working good


Any OS (debian,whonix,kali,kicksecure…) inside Virtualbox with default HM = High degradation in performance leading to almost similar to freeze/pause the OS.


Working good.


Does VirtualBox get slow depending on,

  • VirtualBox on the host and HM on the host, and/or
  • HM inside the VirtualBox VM?

This, When installed inside VM

1 Like

With HM Default on the host and VirtualBox, no issues? No crash issues?

Many possible combinations.

  • Host, VirtualBox, KVM, Qubes.
  • And then also HM on the host, inside a VM, or both.
  • Also HM Default vs HM Light.

To properly document what currently works and what not, could you please check if this HM overview table is correct?


I was looking for a workaround to only exclude Xorg from using HM Default. Nothing great yet. This was my idea:

File /usr/lib/systemd/system/lightdm.service.d/30_hardened-malloc-disable.conf


But that would make /etc/ld.so.preload and therefore HM unused by all applications started lightdm which would include Xorg and all graphical applications.

        |         |-lightdm-+-xfce4-session-+-Thunar---2*[{Thunar}]
        |         |         |               |-VirtualBox---8*[{VirtualBox}]

So wouldn’t be very helpful.

Maybe an AppArmor profile could be abused to prevent Xorg from reading /etc/ld.so.preload? Or some better method?

Should we increase vm.max_map_count = 524240 → 1048576?

1 Like

Thanks! Merged.

Your review all over the place is very much appreciated!

1 Like
1 Like