It'd be interesting to compare the overhead that comes from enabling malloc security features (quarantine, etc.) vs. tracing GC. There has to be some point at which the lines cross and adding more mitigations is more expensive than just using a good tracing GC.
Conversation
Replying to
When you mentioned security, I thought of blackhat.com/docs/us-16/mat and github.com/microsoft/mima can be built in secure mode, adding guard pages, rand allocs, encr free lists, etc. to protect against various heap vuln. The perf penalty is usually around 10% on avg (benchmarked).
1
3
There's a huge range in the amount of hardening an allocator can do. The mimalloc secure mode only has cheap but low value implementations of hardening features. It's not representative of the costs of doing substantial hardening in an allocator.
1
1
11
It still uses inline metadata (free lists, etc.) with only a very weak probabilistic mitigation against corruption. It only uses guard pages to protect the out-of-line metadata, not heap data. It doesn't have quarantines, partitions, zero-on-free or any other expensive features.
1
1
6
Significant hardening will make a micro-benchmark of small allocations an order of magnitude slower (or more). It rules out thread caches or typical lock-free approaches. Need a single, uniform answer to whether an allocation slot is quarantined, freed, etc. and other things.
1
1
7
> It rules out thread caches or typical lock-free approaches. Need a single, uniform answer to whether an allocation slot is quarantined, freed, etc. and other things.
Can you detail why?
1
This is explained further in github.com/GrapheneOS/har. Thread caches are the opposite of a hardened allocator design. A lock-free design has similar issues. A hardened allocator should have perfect knowledge about the state of every allocation to perform consistency checking, etc.
1
2
A hardened allocator should guarantee that free(invalid) is always detected including multiple threads freeing the same allocation. Still possible to have fine-grained locking for arenas and size classes but thread caches and lock-free designs are really counter to the goals.
1
And by guarantee, I mean an actual guarantee, not a weak probabilistic mitigation. It's a natural guarantee in hardened_malloc due to fully out-of-line metadata. It could be done other ways. Most 'hardened' allocators have inline metadata and only weak probabilistic protections.
The performance of hardened_malloc with the expensive optional security features disabled is comparable to glibc malloc without the thread cache enabled. It would be trivial to bolt a thread cache onto hardened_malloc but it inherently ruins a lot of the security properties.