jmb
/
hardened_malloc
mirror of https://github.com/GrapheneOS/hardened_malloc.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

mention that the same hash table code is reused

pull/69/head
Daniel Micay 2018-11-19 05:44:56 -05:00
parent 433b37b4a9
commit d88a8c9813
1 changed files with 12 additions and 11 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

23
README.md
View File

@ -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 This allocator is intended as a successor to a previous implementation based on
extending OpenBSD malloc with various additional security features. It's still 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 heavily based on the OpenBSD malloc design, albeit not on the existing code
original code. The main differences in the design are that it's solely focused other than reusing the hash table implementation for the time being. The main
on hardening rather than finding bugs, uses finer-grained size classes based on differences in the design are that it's solely focused on hardening rather than
jemalloc with slab sizes going beyond 4k, it doesn't rely on the kernel having finding bugs, uses finer-grained size classes based on jemalloc with slab sizes
fine-grained mmap randomization and it only targets 64-bit to make aggressive going beyond 4k, it doesn't rely on the kernel having fine-grained mmap
use of the large address space. There are lots of smaller differences in the randomization and it only targets 64-bit to make aggressive use of the large
implementation approach. It incorporates the previous extensions made to address space. There are lots of smaller differences in the implementation
OpenBSD malloc including adding padding to allocations for canaries (distinct approach. It incorporates the previous extensions made to OpenBSD malloc
from the current OpenBSD malloc canaries), write-after-free detection tied to including adding padding to allocations for canaries (distinct from the current
the existing clearing on free, queues alongside the existing randomized arrays OpenBSD malloc canaries), write-after-free detection tied to the existing
for quarantining allocations and proper double-free detection for quarantined 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 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 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 planned changes to OpenBSD malloc ended up being too extensive and invasive so