From 7f0bbddfcaf7aa6560e52db166059f684ff03a67 Mon Sep 17 00:00:00 2001 From: Daniel Micay Date: Tue, 23 Apr 2019 01:58:37 -0400 Subject: [PATCH] merge points about out-of-line / protected state --- README.md | 23 +++++++++++------------ 1 file changed, 11 insertions(+), 12 deletions(-) diff --git a/README.md b/README.md index 40a5c16..81535b9 100644 --- a/README.md +++ b/README.md @@ -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