jmb/hardened_malloc
1
0
Fork 0
mirror of https://github.com/GrapheneOS/hardened_malloc.git synced 2025-10-27 14:36:32 +01:00
Code Issues Projects Releases Packages Wiki Activity

Improve a bit the formulation of the MTE documentation

Browse source
This commit is contained in:
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
Random tags are set for all slab allocations when allocated. 5 possible 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
left and the current (or previous) tag used for the slot to the right. 3 of
these are dynamic random values. When a slab allocation is freed, the reserved
free tag is set for the slot. Linear overflows are deterministically detected.
Use-after-free has deterministic detection until the freed slot goes through
Random tags are set for all slab allocations when allocated, with 5 excluded values:
1. the default `0` tag
2. a statically *reserved free tag*
3. the previous tag used for the slot
4. the current (or previous) tag used for the slot to the left
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
quarantines again and then finally gets allocated again for a 2nd time. Since
the default 0 tag isn't used, untagged memory can't access malloc allocations
quarantines again and then finally gets allocated again for a 2nd time.
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
data to avoid reducing the possible random tags from 15 to 14, since freed
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
default) are guaranteed to have randomly sized guard regions to the left and
right. Random and FIFO address space quarantines provide use-after-free
detection. Random tags would still be useful for probabilistic detection of
overflows, probabilistic detection of use-after-free once the address space is
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
whether the cost is acceptable for enabling this by default.
detection. We need to test whether the cost of random tags is acceptable to enabled them by default,
since they would be useful for:
- probabilistic detection of overflows
- 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
time and checking canaries are both disabled. Canaries will be more thoroughly
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
time which creates a barrier to optimizing by disabling redundant features.
[very dynamic memory tagging support](https://source.android.com/docs/security/test/memory-safety/arm-mte)
where it can be enabled/disabled at any time which creates a barrier to
optimizing by disabling redundant features.
## API extensions