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

merge points about out-of-line / protected state

pull/87/head
Daniel Micay 2019-04-23 01:58:37 -04:00
parent 409a639312
commit 7f0bbddfca
1 changed files with 11 additions and 12 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

23
README.md
View File

@ -227,7 +227,17 @@ was a bit less important and if a core goal was finding latent bugs.
## Security properties
* Fully out-of-line metadata
* Fully out-of-line metadata/state with protection from corruption
* Address space for allocator state is entirely reserved during
initialization and never reused for allocations or anything else
* State within global variables is entirely read-only after initialization
with pointers to the isolated allocator state so leaking the address of
the library doesn't leak the address of writable state
* Allocator state is located within a dedicated region with high entropy
randomly sized guard regions around it
* Protection via Memory Protection Keys (MPK) on x86\_64 (disabled by
default due to low benefit-cost ratio on top of baseline protections)
* [future] Protection via MTE on ARMv8.5+
* Deterministic detection of any invalid free (unallocated, unaligned, etc.)
* Validation of the size passed for C++14 sized deallocation by `delete`
even for code compiled with earlier standards (detects type confusion if
@ -275,17 +285,6 @@ was a bit less important and if a core goal was finding latent bugs.
size class regions interspersed with guard pages
* Zero size allocations are a dedicated size class with the entire region
remaining non-readable and non-writable
* Protected allocator state (including all metadata)
* Address space for state is entirely reserved during initialization and
never reused for allocations or anything else
* State within global variables is entirely read-only after initialization
with pointers to the isolated allocator state so leaking the address of
the library doesn't leak the address of writable state
* Allocator state is located within a dedicated region with high entropy
randomly sized guard regions around it
* Protection via Memory Protection Keys (MPK) on x86\_64 (disabled by
default due to low benefit-cost ratio on top of baseline protections)
* [future] Protection via MTE on ARMv8.5+
* Extension for retrieving the size of allocations with fallback
to a sentinel for pointers not managed by the allocator
* Can also return accurate values for pointers *within* small allocations