[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #10281 [Applications/Tor Browser]: Investigate usage of alternate memory allocators and memory hardening options
#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@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs