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

explain some differences from the previous project

pull/69/head
Daniel Micay 2018-11-19 01:02:40 -05:00
parent a5ed64d01a
commit a052be762d
1 changed files with 20 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

20
README.md
View File

@ -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 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. 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 # Dependencies
Debian stable determines the most ancient set of supported dependencies: Debian stable determines the most ancient set of supported dependencies: