-
Notifications
You must be signed in to change notification settings - Fork 4
/
Copy pathhardened_malloc.8
38 lines (24 loc) · 4.55 KB
/
hardened_malloc.8
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
.TH "hardened_malloc" "8"
.SH "NAME"
hardened_malloc \- Hardened memory allocator from GrapheneOS
.SH "DESCRIPTION"
The Hard Hat OS project maintains this package for Fedora Linux. The following description of the hardened memory allocator was taken from the project's GitHub page (https://github.com/GrapheneOS/hardened_malloc#introduction):
.IP
"This is a security-focused general purpose memory allocator providing the malloc API along with various extensions. It provides substantial hardening against heap corruption vulnerabilities. The security-focused design also leads to much less metadata overhead and memory waste from fragmentation than a more traditional allocator design. It aims to provide decent overall performance with a focus on long-term performance and memory usage rather than allocator micro-benchmarks. It offers scalability via a configurable number of entirely independent arenas, with the internal locking within arenas further divided up per size class.
This project currently supports Bionic (Android), musl and glibc. It may support other non-Linux operating systems in the future. For Android, there's custom integration and other hardening features which is also planned for musl in the future. The glibc support will be limited to replacing the malloc implementation because musl is a much more robust and cleaner base to build on and can cover the same use cases.
This allocator is intended as a successor to a previous implementation based on extending OpenBSD malloc with various additional security features. It's still heavily based on the OpenBSD malloc design, albeit not on the existing code other than reusing the hash table implementation. The main differences in the design are that it's solely focused on hardening rather than finding bugs, uses finer-grained size classes along with slab sizes going beyond 4k to reduce internal fragmentation, doesn't rely on the kernel having fine-grained mmap randomization and only targets 64-bit to make aggressive use of the large address space. There are lots of smaller differences in the implementation approach. It incorporates the previous extensions made to OpenBSD malloc including adding padding to allocations for canaries (distinct from the current OpenBSD malloc canaries), write-after-free detection tied to the existing clearing on free, queues alongside the existing randomized arrays for quarantining allocations and proper double-free detection for quarantined allocations. The per-size-class memory regions with their own random bases were loosely inspired by the size and type-based partitioning in PartitionAlloc. The planned changes to OpenBSD malloc ended up being too extensive and invasive so this project was started as a fresh implementation better able to accomplish the goals. For 32-bit, a port of OpenBSD malloc with small extensions can be used instead as this allocator fundamentally doesn't support that environment."
.SH ENABLE
The hardened memory allocator has two variants:
.B default
and
.B light
as described on the project's GitHub page (https://github.com/GrapheneOS/hardened_malloc#configuration):
.IP
"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."
.PP
By default, the light
variant is enabled globally within the
.I /etc/ld.so.preload
file. This provides a decent trade-off between security and usability, but the default variant can be enabled globally by following the instructions within the file. It's important to note that enabling the default variant globally may break your system, so proceed with caution.
.SH AUTHOR
GrapheneOS (https://github.com/GrapheneOS/hardened_malloc)