From d88a8c98137a7adba9dd0df0545873b1986a6d33 Mon Sep 17 00:00:00 2001 From: Daniel Micay Date: Mon, 19 Nov 2018 05:44:56 -0500 Subject: [PATCH] mention that the same hash table code is reused --- README.md | 23 ++++++++++++----------- 1 file changed, 12 insertions(+), 11 deletions(-) diff --git a/README.md b/README.md index 1fe62a1..61ea1d8 100644 --- a/README.md +++ b/README.md @@ -15,17 +15,18 @@ 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 +heavily based on the OpenBSD malloc design, albeit not on the existing code +other than reusing the hash table implementation for the time being. 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