Improve a bit the formulation of the MTE documentation

README.md

@@ -724,19 +724,26 @@ 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
+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
-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
+When a slab allocation is freed, the *reserved free tag* is set for the slot.
-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
+This ensures the following properties:
-data to avoid reducing the possible random tags from 15 to 14, since freed
+
-data is always zeroed anyway.
+- 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
+  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.
 
 Slab allocations are done in a statically reserved region for each size class
 and all metadata is in a statically reserved region, so interactions between
@@ -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
+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
 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
+[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