#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 _______________________________________________ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs