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.
> 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
Show replies