From c4fc025fde2f1dd6e2f4f20db36c09165458b719 Mon Sep 17 00:00:00 2001 From: Daniel Micay Date: Sun, 18 Aug 2019 05:35:48 -0400 Subject: [PATCH] clarify ZERO_ON_FREE / WRITE_AFTER_FREE_CHECK --- README.md | 13 ++++++++----- 1 file changed, 8 insertions(+), 5 deletions(-) diff --git a/README.md b/README.md index c16e6aa..855c49b 100644 --- a/README.md +++ b/README.md @@ -185,12 +185,15 @@ The following boolean configuration options are available: allocations are zeroed on free, to mitigate use-after-free and uninitialized use vulnerabilities along with purging lots of potentially sensitive data from the process as soon as possible. This has a performance cost scaling to - the size of the allocation, which is usually acceptable. + the size of the allocation, which is usually acceptable. This is not relevant + to large allocations because the pages are given back to the kernel. * `CONFIG_WRITE_AFTER_FREE_CHECK`: `true` (default) or `false` to control - sanity checking that new allocations contain zeroed memory. This can detect - writes caused by a write-after-free vulnerability and mixes well with the - features for making memory reuse randomized / delayed. This has a performance - cost scaling to the size of the allocation, which is usually acceptable. + sanity checking that new small allocations contain zeroed memory. This can + detect writes caused by a write-after-free vulnerability and mixes well with + the features for making memory reuse randomized / delayed. This has a + performance cost scaling to the size of the allocation, which is usually + acceptable. This is not relevant to large allocations because they're always + a fresh memory mapping from the kernel. * `CONFIG_SLOT_RANDOMIZE`: `true` (default) or `false` to randomize selection of free slots within slabs. This has a measurable performance cost and isn't one of the important security features, but the cost has been deemed more