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

Improve a bit the formulation of the MTE documentation

pull/232/merge
Julien Voisin 2024-01-03 19:39:24 +01:00 committed by Daniel Micay
parent abe54dba27
commit 53a45b4661
1 changed files with 30 additions and 20 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

42
README.md
View File

@ -724,16 +724,23 @@ freeing as there would be if the kernel supported these features directly.
## Memory tagging ## Memory tagging
Random tags are set for all slab allocations when allocated. 5 possible values Random tags are set for all slab allocations when allocated, with 5 excluded values:
are excluded: the default 0 tag, a statically reserved free tag, the previous
tag used for the slot, the current (or previous) tag used for the slot to the 1. the default `0` tag
left and the current (or previous) tag used for the slot to the right. 3 of 2. a statically *reserved free tag*
these are dynamic random values. When a slab allocation is freed, the reserved 3. the previous tag used for the slot
free tag is set for the slot. Linear overflows are deterministically detected. 4. the current (or previous) tag used for the slot to the left
Use-after-free has deterministic detection until the freed slot goes through 5. the current (or previous) tag used for the slot to the right
When a slab allocation is freed, the *reserved free tag* is set for the slot.
This ensures the following properties:
- Linear overflows are deterministically detected.
- Use-after-free are deterministically detected until the freed slot goes through
both the random and FIFO quarantines, gets allocated again, goes through both both the random and FIFO quarantines, gets allocated again, goes through both
quarantines again and then finally gets allocated again for a 2nd time. Since quarantines again and then finally gets allocated again for a 2nd time.
the default 0 tag isn't used, untagged memory can't access malloc allocations Since the default `0` tag isn't used, untagged memory can't access malloc allocations
and vice versa, although it may make sense to reuse the default tag for free and vice versa, although it may make sense to reuse the default tag for free
data to avoid reducing the possible random tags from 15 to 14, since freed data to avoid reducing the possible random tags from 15 to 14, since freed
data is always zeroed anyway. data is always zeroed anyway.
@ -745,17 +752,20 @@ different uses of the same address space is not applicable.
Large allocations beyond the largest slab allocation size class (128k by Large allocations beyond the largest slab allocation size class (128k by
default) are guaranteed to have randomly sized guard regions to the left and default) are guaranteed to have randomly sized guard regions to the left and
right. Random and FIFO address space quarantines provide use-after-free right. Random and FIFO address space quarantines provide use-after-free
detection. Random tags would still be useful for probabilistic detection of detection. We need to test whether the cost of random tags is acceptable to enabled them by default,
overflows, probabilistic detection of use-after-free once the address space is since they would be useful for:
out of the quarantine and reused for another allocation and deterministic
detection of use-after-free for reuse by another allocator. We need to test - probabilistic detection of overflows
whether the cost is acceptable for enabling this by default. - probabilistic detection of use-after-free once the address space is
out of the quarantine and reused for another allocation
- deterministic detection of use-after-free for reuse by another allocator.
When memory tagging is enabled, checking for write-after-free at allocation When memory tagging is enabled, checking for write-after-free at allocation
time and checking canaries are both disabled. Canaries will be more thoroughly time and checking canaries are both disabled. Canaries will be more thoroughly
disabled when using memory tagging in the future, but Android currently has disabled when using memory tagging in the future, but Android currently has
very dynamic memory tagging support where it can be enabled/disabled at any [very dynamic memory tagging support](https://source.android.com/docs/security/test/memory-safety/arm-mte)
time which creates a barrier to optimizing by disabling redundant features. where it can be enabled/disabled at any time which creates a barrier to
optimizing by disabling redundant features.
## API extensions ## API extensions