@musllibc @RichFelker Bionic and glibc use the XOR mitigation for setjmp. Bionic does it for all of the registers. Not sure about glibc.
@CopperheadSec I'm generally of the view that "modern performance-oriented allocators" are a load of crap. :-)
-
-
@CopperheadSec Headers/footers, if validated well, also go a long way towards mitigating exploitable off-by-1 heap overflows. -
@RichFelker They are, but it can be better without the metadata there at all. Spending two extra bits per allocation isn't very significant. -
@CopperheadSec I've considered size-segregated pools with atomic TAS bitmaps to solve frag, overhead, and lock contention.
End of conversation
New conversation -
-
-
@RichFelker Reducing metadata overhead to a bit or two per allocation rather than nearly doubling small allocation size is quite useful. -
@RichFelker Offering precise first-best-fit like jemalloc also goes a long way towards reducing fragmentation but O(log n) instead of O(1). -
@RichFelker Small fixed-size thread caches are incredible for improving performance, rather than reducing contention (many ops per lock). -
@CopperheadSec I agree there are some potentially good ideas. Going to explore them for@musllibc's next gen malloc. -
@CopperheadSec@musllibc I just don't accept that multi-MB heap granularity, heavy per-thread overhead, etc. are reasonable. -
@RichFelker@musllibc The multi-megabyte granularity comes from the alignment-based metadata. Lowering it means higher metadata overhead. -
@CopperheadSec % overhead is fairly inconsequential. Large O(1) overhead sucks. n->0 asymptotics matter as much as n->∞. (e.g. 4 lg nprocs). -
@RichFelker The region alignment design provides cheap, low-overhead metadata. There's pressure for larger regions for various reasons. - 9 more replies
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.