From a052be762dfad21cac0b466182d85d3b6d59036f Mon Sep 17 00:00:00 2001 From: Daniel Micay Date: Mon, 19 Nov 2018 01:02:40 -0500 Subject: [PATCH] explain some differences from the previous project --- README.md | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+) diff --git a/README.md b/README.md index 36dded8..e93c8b9 100644 --- a/README.md +++ b/README.md @@ -13,6 +13,26 @@ will be custom integration and other hardening features. The glibc support will be limited to replacing the malloc implementation because musl is a much more robust and cleaner base to build on and can cover the same use cases. +This allocator is intended as a successor to a previous implementation based on +extending OpenBSD malloc with various additional security features. It's still +heavily based on the OpenBSD malloc design, albeit with only a few bits of the +original code. The main differences in the design are that it's solely focused +on hardening rather than finding bugs, uses finer-grained size classes based on +jemalloc with slab sizes going beyond 4k, it doesn't rely on the kernel having +fine-grained mmap randomization and it only targets 64-bit to make aggressive +use of the large address space. There are lots of smaller differences in the +implementation approach. It incorporates the previous extensions made to +OpenBSD malloc including adding padding to allocations for canaries (distinct +from the current OpenBSD malloc canaries), write-after-free detection tied to +the existing clearing on free, queues alongside the existing randomized arrays +for quarantining allocations and proper double-free detection for quarantined +allocations. The per-size-class memory regions with their own random bases were +loosely inspired by the size and type-based partitioning in PartitionAlloc. The +planned changes to OpenBSD malloc ended up being too extensive and invasive so +this project was started as a fresh implementation better able to accomplish +the goals. For 32-bit, a port of OpenBSD malloc with small extensions can be +used instead as this allocator fundamentally doesn't support that environment. + # Dependencies Debian stable determines the most ancient set of supported dependencies: