[tor-dev] TBB Memory Allocator choice fingerprint implications

[Daniel Micay]

On Wed, 21 Aug 2019 at 16:28, Ryan Duff <ry at nduff.com> wrote:
>
> > If someone is going to criticize other people's work and dismiss it as
> nearly useless without even somewhat informing themselves about it,
> they should expect to be called out on that.
>
> I don't have a dog in this fight but, as an outside observer, I never got the impression that this is what Tom was doing. I read it as "hardened_malloc is better but we are trying to do these n things to try to close that gap". I didn't read it as an attack at all.

Skipping actually reading the documentation about what it does and
dismissing it as only being a couple features that could be added to
jemalloc is ignorant misinformation and what I find offensive.
Presenting it as a situation where they could simply bolt on some
security features to jemalloc and provide something comparable is the
problem. The list was also ridiculous, and simply wrong. What I found
dishonest is that it's portrayed as if it's an expert's assessment of
the differences rather than a bunch of poorly informed assumptions and
assorted misinformation. It was not a fair attempt to actually
evaluate hardened_malloc and compare it, but rather a lazy attempt to
dismiss it and downplay the advantages on the security front. Now,
consider that this is a personal project that I work on, using my own
time, with only donations supporting my work. It's not a product from
a company or a collaborative project. No one else has written a single
line of code in it, or played a role in the design. It's an attack on
my work, and myself, including my credibility since I present it as
having substantial advantages and here's this person who seems like an
expert on the topic (but hasn't even read the README or looked in any
detail at it) from Mozilla dismissing it.

The gap between a hardened allocator design and a performance-oriented
allocator design has if anything been widening due to divergence in
design trade-offs / compromises. The glibc allocator recently got a
lot worse on the security front (it was already awful) by adding
thread caching, which is fantastic for performance. There have been
many similar performance improvements in jemalloc reducing security in
the past couple years.

Memory tagging is only going to increase the divergence with how many
possibilities it opens up and how well it synergizes with hardened
allocator designs.