provides more details on hardened_malloc
This commit is contained in:
parent
d8450922c6
commit
6728a8a24d
@ -101,17 +101,45 @@
|
|||||||
<li><a href="https://github.com/GrapheneOS/platform_bionic">Hardened libc</a>
|
<li><a href="https://github.com/GrapheneOS/platform_bionic">Hardened libc</a>
|
||||||
providing defenses against the most common classes of vulnerabilities (memory
|
providing defenses against the most common classes of vulnerabilities (memory
|
||||||
corruption)</li>
|
corruption)</li>
|
||||||
<li>Our own <a href="https://github.com/GrapheneOS/hardened_malloc">hardened malloc (memory allocator)</a>
|
<li>
|
||||||
leveraging modern hardware capabilities to provide substantial defenses against
|
Our own <a href="https://github.com/GrapheneOS/hardened_malloc">hardened
|
||||||
the most common classes of vulnerabilities (heap memory corruption) along with
|
malloc (memory allocator)</a> leveraging modern hardware capabilities
|
||||||
reducing the lifetime of sensitive data in memory. The
|
to provide substantial defenses against the most common classes of
|
||||||
<a href="https://github.com/GrapheneOS/hardened_malloc/blob/main/README.md">hardened_malloc
|
vulnerabilities (heap memory corruption) along with reducing the lifetime
|
||||||
README</a> has extensive documentation on it. The hardened_malloc project is
|
of sensitive data in memory. The <a
|
||||||
portable to other Linux-based operating systems and is being adopted by other
|
href="https://github.com/GrapheneOS/hardened_malloc/blob/main/README.md">hardened_malloc
|
||||||
security-focused operating systems like Whonix. Our allocator also heavily influenced the
|
README</a> has extensive documentation on it. The hardened_malloc
|
||||||
design of the <a href="https://www.openwall.com/lists/musl/2020/05/13/1">next-generation
|
project is portable to other Linux-based operating systems and is being
|
||||||
musl malloc implementation</a> which offers substantially better security than musl's
|
adopted by other security-focused operating systems like Whonix. Our
|
||||||
previous malloc while still having minimal memory usage and code size.</li>
|
allocator also heavily influenced the design of the <a
|
||||||
|
href="https://www.openwall.com/lists/musl/2020/05/13/1">next-generation
|
||||||
|
musl malloc implementation</a> which offers substantially better security than
|
||||||
|
musl's previous malloc while still having minimal memory usage and code size.
|
||||||
|
<ul>
|
||||||
|
<li>Fully out-of-line metadata with protection from corruption, ruling
|
||||||
|
out traditional allocator exploitation</li>
|
||||||
|
<li>Separate memory regions for metadata, large allocations and each
|
||||||
|
slab allocation size class with high entropy random bases and no
|
||||||
|
address space reuse between the different regions</li>
|
||||||
|
<li>Determistic detection of any invalid free</li>
|
||||||
|
<li>Zero-on-free with detection of write-after-free via checking that
|
||||||
|
memory is still zeroed before handing it out again</li>
|
||||||
|
<li>Delayed reuse of address space and memory allocations through the
|
||||||
|
combination of deterministic and randomized quarantines to mitigate
|
||||||
|
use-after-free vulnerabilities</li>
|
||||||
|
<li>Fine-grained randomization</li>
|
||||||
|
<li>Aggressive consistency checks</li>
|
||||||
|
<li>Memory protected guard regions around allocations larger than 16k
|
||||||
|
with randomization of guard region sizes for 128k and above</li>
|
||||||
|
<li>Allocations smaller than 16k have guard regions around each of the
|
||||||
|
slabs containing allocations (for example, 16 byte allocations are in
|
||||||
|
4096 byte slabs with 4096 byte guard regions before and after)</li>
|
||||||
|
<li>Random canaries with a leading zero are added to these smaller
|
||||||
|
allocations to block C string overflows, absorb small overflows
|
||||||
|
and detect linear overflows or other heap corruption when the
|
||||||
|
canary value is checked (primarily on free)</li>
|
||||||
|
</ul>
|
||||||
|
</li>
|
||||||
<li>Hardened compiler toolchain</li>
|
<li>Hardened compiler toolchain</li>
|
||||||
<li>
|
<li>
|
||||||
Hardened kernel
|
Hardened kernel
|
||||||
|
Loading…
x
Reference in New Issue
Block a user