- add configuration variant system with two standard recommended configurations:
default
for an aggressive security-focused configuration andlight
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 standarddefault
andlight
configuration. You can choose the configuration to build usingmake VARIANT=light
wheremake VARIANT=default
is the same asmake
. Non-default configuration templates will build a library with the suffix-variant
such aslibhardened_malloc-light.so
and will use anout-variant
directory instead ofout
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.
Debian Host:
Debian stable with default/full HM = working good
Virtualbox:
Any OS (debian,whonix,kali,kicksecure…) inside Virtualbox with default HM = High degradation in performance leading to almost similar to freeze/pause the OS.
KVM:
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
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?
https://www.kicksecure.com/wiki/Hardened_Malloc#Graphical_Desktop_Environment_Xorg
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
[Service]
InaccessiblePaths=-/etc/ld.so.preload
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.
pstree
|-lightdm-+-Xorg---{Xorg}
| |-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?
Thanks! Merged.
Your review all over the place is very much appreciated!