From dba330fde73be42ec36cabd2486a40182257d980 Mon Sep 17 00:00:00 2001 From: Daniel Micay Date: Thu, 30 Aug 2018 11:07:20 -0400 Subject: [PATCH] expand documentation in the README --- README.md | 52 ++++++++++++++++++++++++++++++++++++++++++++++++---- 1 file changed, 48 insertions(+), 4 deletions(-) diff --git a/README.md b/README.md index 178fcea..85af52d 100644 --- a/README.md +++ b/README.md @@ -8,6 +8,10 @@ However, using more recent releases is highly recommended. Older versions of the dependencies may be compatible at the moment but are not tested and will explicitly not be supported. +Ports to Android (Bionic libc) and musl libc will be created later. The initial +target is glibc for ease of development, since it supports replacing the malloc +implementation at runtime using dynamic linking including via `LD_PRELOAD`. + # Basic design The current design is very simple and will become a bit more sophisticated as @@ -37,10 +41,16 @@ allocation and then unmapped on free. * Fully out-of-line metadata * Deterministic detection of any invalid free (unallocated, unaligned, etc.) * Isolated memory region for slab allocations - * Divided up into isolated inner regions for each size class, with a high - entropy random base for each one - * No deterministic offsets from one size class to another + * Divided up into isolated inner regions for each size class + * High entropy random base for each size class region + * No deterministic / low entropy offsets between allocations with + different size classes * Metadata is completely outside the slab allocation region + * No references to metadata within the slab allocation region + * No deterministic / low entropy offsets to metadata + * Entire slab region starts out non-readable and non-writable + * Slabs beyond the cache limit are purged and become non-readable and + non-writable memory again * Fine-grained randomization within memory regions * Randomly sized guard regions for large allocations * Random slot selection within slabs @@ -63,11 +73,45 @@ allocation and then unmapped on free. leaving slab size class regions interspersed with guard pages * Zero size allocations are memory protected * [mostly in-progress] Protected allocator metadata -* [in-progress] Extension for retrieving the size of allocations with fallback +* 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 * The same applies to pointers within the first page of large allocations, otherwise it currently has to return a sentinel +* No alignment tricks interfering with ASLR like jemalloc, PartitionAlloc, etc. +* No usage of the legacy brk heap +* Aggressive sanity checks + * Errors other than ENOMEM from mmap, munmap, mprotect and mremap treated + as fatal, which can help to decent memory management gone wrong elsewhere + in the program + +# Randomness + +The current implementation of random number generation for randomization-based +mitigations is based on generating a keystream from a stream cipher (ChaCha8) +in small chunks. A separate CSPRNG is used for each small size class, large +allocations, etc. in order to fit into the existing fine-grained locking model +without needing to waste memory per thread by having the CSPRNG state in Thread +Local Storage. Similarly, it's protected via the same approach taken for the +rest of the metadata. The stream cipher is regularly reseeded from the OS to +provide backtracking and prediction resistance with a negligible cost. The +reseed interval simply needs to be adjusted to the point that it stops +registering as having any significant performance impact. The performance +impact on recent Linux kernels is primarily from the high cost of system calls +and locking since the implementation is quite efficient (ChaCha20), especially +for just generating the key and nonce for another stream cipher (ChaCha8). + +ChaCha8 is a great fit because it's extremely fast across platforms without +relying on hardware support or complex platform-specific code. The security +margins of ChaCha20 would be completely overkill for the use case. Using +ChaCha8 avoids needing to resort to a non-cryptographically secure PRNG or +something without a lot of scrunity. The current implementation is simply the +reference implementation of ChaCha8 converted into a pure keystream by ripping +out the XOR of the message into the keystream. + +The random range generation functions are a highly optimized implementation +too. Traditional uniform random number generation within a range is very high +overhead and can easily dwarf the cost of an efficient CSPRNG. # Size classes