explain some differences from the previous project
This commit is contained in:
parent
a5ed64d01a
commit
a052be762d
20
README.md
20
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:
|
||||
|
Loading…
Reference in New Issue
Block a user