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

update documentation based on light configuration

pull/187/head
Daniel Micay 2022-01-12 08:58:00 -05:00
parent a6d27848af
commit efd71e70c7
1 changed files with 15 additions and 18 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

33
README.md
View File

@ -200,6 +200,21 @@ is the same as `make`. Non-default configuration templates will build a library
with the suffix `-variant` such as `libhardened_malloc-light.so` and will use with the suffix `-variant` such as `libhardened_malloc-light.so` and will use
an `out-variant` directory instead of `out` for the build. an `out-variant` directory instead of `out` for the build.
The `default` configuration template has all normal optional security features
enabled (just not the niche `CONFIG_SEAL_METADATA`) and is quite aggressive in
terms of sacrificing performance and memory usage for security. The `light`
configuration template disables the slab quarantines, write after free check,
slot randomization and raises the guard slab interval from 1 to 8 but leaves
zero-on-free and slab canaries enabled. The `light` configuration has solid
performance and memory usage while still being far more secure than mainstream
allocators with much better security properties. Disabling zero-on-free would
gain more performance but doesn't make much difference for small allocations
without also disabling slab canaries. Slab canaries slightly raise memory use
and slightly slow down performance but are quite important to mitigate small
overflows and C string overflows. Disabling slab canaries is not recommended
in most cases since it would no longer be a strict upgrade over traditional
allocators with headers on allocations and basic consistency checks for them.
For reduced memory usage at the expense of performance (this will also reduce For reduced memory usage at the expense of performance (this will also reduce
the size of the empty slab caches and quarantines, saving a lot of memory, the size of the empty slab caches and quarantines, saving a lot of memory,
since those are currently based on the size of the largest size class): since those are currently based on the size of the largest size class):
@ -208,24 +223,6 @@ since those are currently based on the size of the largest size class):
N_ARENA=1 \ N_ARENA=1 \
CONFIG_EXTENDED_SIZE_CLASSES=false CONFIG_EXTENDED_SIZE_CLASSES=false
The default configuration has all normal security features enabled (just not
the niche `CONFIG_SEAL_METADATA`) and is quite aggressive in terms of
sacrificing performance and memory usage for security. An example of a leaner
configuration disabling expensive security features other than zero-on-free /
slab canaries along with using far fewer guard slabs:
make \
CONFIG_WRITE_AFTER_FREE_CHECK=false \
CONFIG_SLOT_RANDOMIZE=false \
CONFIG_SLAB_QUARANTINE_RANDOM_LENGTH=0 \
CONFIG_SLAB_QUARANTINE_QUEUE_LENGTH=0 \
CONFIG_GUARD_SLABS_INTERVAL=8
This is a more appropriate configuration for a more mainstream OS choosing to
use hardened\_malloc while making a smaller memory and performance sacrifice.
The slot randomization isn't particularly expensive but it's low value and is
one of the first things to disable when aiming for higher performance.
The following boolean configuration options are available: The following boolean configuration options are available:
* `CONFIG_WERROR`: `true` (default) or `false` to control whether compiler * `CONFIG_WERROR`: `true` (default) or `false` to control whether compiler