By default, hardened_malloc enables all the available security features and is aggressively tuned for security over throughput and memory usage based on the needs of GrapheneOS. I added a sensible leaner configuration option to the README as an example:
github.com/GrapheneOS/har
Conversation
It also has an example of reducing memory usage at the expense of performance. It can be combined with the leaner configuration for the security features.
I'm also going to look into making the quarantine configuration options more flexible so smaller quarantines can be used.
1
The quarantine system is per-size-class due to the design. The minimum quarantine size for slab allocations is currently based on the size of the largest slab size class so there's always room for at least one allocation in the quarantine. That's probably too inflexible though.
1
The largest slab size class is either 16k or 128k based on CONFIG_EXTENDED_SIZE_CLASSES. 16k is the final size class spaced by less than 4096 bytes from the previous one, so it can't be smaller than that. 128k is an arbitrary compromise for better performance and is the default.
1
1
Both random and queue quarantines are enabled by default, resulting in 256k of quarantined allocations per slab size class or 32k with !CONFIG_EXTENDED_SIZE_CLASSES. Can currently only disable these or raise the multiplier, but it should be possible to make this more flexible.
1
1
Talked about this with along with the possibility of detecting that every allocation in a slab is either freed or quarantined, rather than only detecting if every allocation is freed. Quarantine already adds an extra bitmap to slab metadata for detecting double-free.
2
2
Purging allocations in the quarantine could make the performance cost substantially higher. This is a particularly tricky feature to improve. It's one of the most expensive security features despite already trying to optimize it already including clamping slots to powers of 2.