[tor-bugs] #10281 [Applications/Tor Browser]: Investigate usage of alternate memory allocators and memory hardening options

[Tor Bug Tracker & Wiki]

#10281: Investigate usage of alternate memory allocators and memory hardening
options
-------------------------------------------------+-------------------------
 Reporter:  mikeperry                            |          Owner:
                                                 |  arthuredelstein
     Type:  enhancement                          |         Status:  closed
 Priority:  Very High                            |      Milestone:
Component:  Applications/Tor Browser             |        Version:
 Severity:  Normal                               |     Resolution:  fixed
 Keywords:  tbb-security, tbb-hardened,          |  Actual Points:
  TorBrowserTeam201612R                          |
Parent ID:  #20955                               |         Points:
 Reviewer:                                       |        Sponsor:
                                                 |  SponsorU
-------------------------------------------------+-------------------------

Comment (by tom):

 I'm pasting this here from an email I wrote in Sept 2016.

 > The original problem with PartitionAlloc was the lack of memalign
 > functions and the need to implement them.  They don't seem to have been
 > added, so that problem persists.

 See https://github.com/struct/HardenedPartitionAlloc/issues/1

 > There seem to be some security
 > features that are in OpenBSD's allocator that aren't/can't be in
 > PartitionAlloc, but not all of them.
 >
 > - No inline metadata - PartitionAlloc has this feature as well.
 > - "It is guaranteed to abort for pointers that are not active malloc
 allocations." - not sure about this, but
 http://struct.github.io/partition_alloc.html has a patch for
 PartitionAlloc that does check the freelist for double frees. I'm not sure
 if this is a comprehensive equality of features though
 > - "sets the allocator to abort on out-of-memory by default" - This is
 probably pretty easy to do. (Just a NULL check and an abort() no?)
 > - "Fine-grained randomization is performed for small allocations by
 choosing a random pool to satisfy requests" - okay, but this is like
 'choose a random partition' except not as powerful, cause you're in the
 same heap
 > - "and then choosing a random free slot within a page provided by that
 pool" - PartitionAlloc does not have this, but it could. Here's a patch:
 http://struct.github.io/partition_alloc.html
 > - "Freed small allocations are quarantined before being put back into
 circulation via a randomized delayed allocation pool" - okay,
 PArtitionAlloc doesn't have this
 > - "CopperheadOS uses a ring buffer..." PartitionAlloc doesn't have this
 > - "Small allocations are filled with junk data upon being released." -
 this is easily added
 > - "Canaries can be placed at the end of small allocations to absorb
 small overflows and catch various forms of heap corruption upon free. This
 was a successfully upstreamed CopperheadOS extension. " - PartitionAlloc
 doesn't have this
 >
 >
 >
 > I looked at OpenBSD's allocator, which AFAICT is in openbsd's
 > src/lib/libc/stdlib/malloc.c
 > It contains an implementation of the needed functions: malloc,
 > posix_memalign, calloc, realloc, free, and usable_size
 > It does not contain an implementation of the following, but they should
 > be simple enough to implement: memalign, alligned_alloc, valloc,
 good_size
 >
 > So I think it would be possible to get OpenBSD's allocator in without a
 > ton of pain... But the main things OpenBSD's allocator seems to lack is
 > any sort of partitioning.  So the real gains that Chrome saw and made
 > was moving Layout Objects and Buffer Objects to their own partitions.
 >
 >
 >
 > So that brings us to jemalloc. As far as integration goes: Mozilla has
 > merged in jemalloc 4, but it seems to have a lot of bugs filed against
 > it. Some try results seemed to pass on 4.1.1 but failed on 4.2.  It
 > seems the best thing to do to figure out it's stability is to sit down
 > with Mike Hommey and ask: if we want to enable jemalloc 3, or 4; how
 > stable is it?

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/10281#comment:49>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online