This is a meta bug for tracking mozjemalloc security improvements.

There are a few sub-bugs I did not file because I thought they would not be valuable/feasible. They are: Read-Only Allocator Configuration. If we had runtime allocator configuration stored in memory, we could store that configuration in read-only memory to prevent an attacker from mucking with things (like canary values). But I don't think we have such a configuration in memory, or if we do I don't think it has security implications. (Could always be wrong though!) Delay Free Allocations. Hold onto objects for a bit before actually freeing them and releasing them. Not very effective, because the attacker can generally cause the free cache to flush deterministicly. Detecting Write-after-Free via the Delay Free Cache. When something goes into the Free Cache, poison it with a value. When GC-ing the freecache, check that all bytes are the poison value. (Would be quite slow.) Allocation Canaries. Stick some canary bytes at the end of every allocation, and during free() make sure they're not overwritten. Not terribly helpful since it's only during free, so maybe use a background thread just checking everything randomly. Memory usage++ and slow.

Finally, since I just files a bunch of bugs I want to be clear about what is most valuable. 1) Memory Partitioning. This is out of the allocator's hands at this point (except for Bug 1446046 and other non-security blockers) 2) Heap out of line metadata: Bug 1446045 Everything else is an order of magnitude less important, but Guard Pages (Bug 1446040) would be the most valuable of those (and probably not very difficult.)

Something else we've talked about before that seems somewhat related is ensuring that the poison value we use in mozjemalloc isn't valid memory.

(In reply to Andrew McCreight [:mccr8] from comment #3) > Something else we've talked about before that seems somewhat related is > ensuring that the poison value we use in mozjemalloc isn't valid memory. It's not, at least on tier-1 platforms.