emo/hardened_malloc
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

cleaner wording in introduction

Browse Source
This commit is contained in:
Daniel Micay 2019-08-18 06:47:00 -04:00
parent c66cf10894
commit 0af33616f0
1 changed files with 11 additions and 11 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

22
README.md
View File

@ -42,17 +42,17 @@ 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 not on the existing code 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 other than reusing the hash table implementation. The main differences in the
differences in the design are that it is solely focused on hardening rather design are that it's solely focused on hardening rather than finding bugs, uses
than finding bugs, uses finer-grained size classes along with slab sizes going finer-grained size classes along with slab sizes going beyond 4k to reduce
beyond 4k to reduce internal fragmentation, doesn't rely on the kernel having internal fragmentation, doesn't rely on the kernel having fine-grained mmap
fine-grained mmap randomization and only targets 64-bit to make aggressive use randomization and only targets 64-bit to make aggressive use of the large
of the large address space. There are lots of smaller differences in the address space. There are lots of smaller differences in the implementation
implementation approach. It incorporates the previous extensions made to approach. It incorporates the previous extensions made to OpenBSD malloc
OpenBSD malloc including adding padding to allocations for canaries (distinct including adding padding to allocations for canaries (distinct from the current
from the current OpenBSD malloc canaries), write-after-free detection tied to OpenBSD malloc canaries), write-after-free detection tied to the existing
the existing clearing on free, queues alongside the existing randomized arrays clearing on free, queues alongside the existing randomized arrays for
for quarantining allocations and proper double-free detection for quarantined 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