support ARMv8.5 memory tagging

[thestinger]

Generating the tags is going to require careful thought. Adjacent allocations should be guaranteed to have different tags, which could be approached by dedicating a bit to whether the slot is at an odd or even index (wasting entropy) or by generating a new random tag until there's no collision which requires a way to fetch the tags from the shadow region or wasting memory on metadata in the allocator.

The existing CSPRNG (ChaCha8 keystream with a small cache) is very efficient and will make generating these tags low overhead, but using a couple more bytes on every allocation will further increase the pressure to optimize it, especially alongside further slab allocation randomization beyond the existing slot selection randomization.

[thestinger]

Another example of a deterministic mitigation is reserving a tag value for freed memory and setting it on free.

The slab allocator can also store the previous random tag in the freed slot and increment it (cyclically) for the next allocation in that slot instead of generating a fresh random tag. It just needs to skip past the values reserved for free memory and the adjacent allocations, similarly to how those would be rejected for a freshly generated random value.

[jvoisin]

As said on matrix:

best way to do this is making a simple little library for generic MTE use
abstracting the stuff
start with simply doing this: reserve 1 tag for internal use, generate and set random tag for slab allocations on allocation, set to tag for internal use on free
and there are instructions for zeroing the memory + setting tag at the same time
can go from there
could then make it smarter by figuring out how to make sure adjacent tags are always different
and then doing the tag cycling thing I proposed in README
but the basic implementation is just random tags for slab allocations + set to reserved internal use tag on free (which has to be reserved ofc)
you could start with even simpler: reserve 1 tag, set the reserved tag on the freed memory, unset it when allocating
it's 16 byte memory protection with 4-bit keys inside upper bits of pointers with instructions for generating random ones automatically (skipping reserved tags), clearing memory at same time, etc.
eventually we can't use the functions for generating random ones since we need more thoughtful choice than that
could just skip using it 
basically we can and want to use it in a very sophisticated way but simply getting anything working is fine
and it's best to start with only slab allocations
it's probably too expensive to tag large ones, I think it probably forces all the memory to be allocated (along with the tag data)

[flawedworld]

~ outline to perform initial testing

sudo pacman -S qemu qemu-arch-extra virt-manager

Create aarch64 VM (Can just be Arch Linux ARM) with virt-manager (for ease).

Once VM is working, pass mte=on to machine definition.

[jvoisin]

isoalloc recently added support for MTE.

[thestinger]

@jvoisin No, doesn't appear they did. They added software tagging based on TBI (Top Byte Ignore) which doesn't have checks for temporal or bounds issues in the code using it. It doesn't do very much.

[flawedworld]

https://cs.android.com/android/platform/superproject/+/master:device/generic/goldfish/fvpbase/README.md