CHERI provides actual hardware enforced protection. MTE exists to find potential security bugs but no real protection. You've got a 4 bit tag, which an application can forge so if some attacker needed to forge the correct tag they could choose randomly and be right 1/16th of the time. The idea is when MTE is employed you'll get bad accesses occurring occasionally that aren't due to an attacker and don't actually cause anything bad to happen (imagine a typical buffer overflow, it may well be the words immediately beyond the end of the buffer aren't being but to any other purpose so using them actually works). MTE will detect these and they can be investigated and patched before they can get turned into a weaponised exploit.
MTE is actual hardware enforced protection, but simply doesn't have enough bits to reliably detect memory corruption in the general case. It's able to provide a lot of useful deterministic security properties via reserved tags. Normally, the 0 tag is reserved since that's what's used for untagged memory so the random choice never chooses 0. You can also exclude other values, statically or dynamically. This means you can leave things untagged but with PROT_MTE enabled to prevent any tagged pointer accessing them. For example, if you leave register spills, return pointer, etc. untagged then if all stack allocations with potential overflows / use-after-scope are tagged they cannot access that data. As another example, you typically use 0 as the value for currently free allocations which protects them until being allocated again. You can dynamically exclude the adjacent allocations to catch 100% of small/linear overflows along with excluding previous allocation tags. We do this in hardened_malloc with the most recent tags for the 2 adjacent allocations (i.e. current tag if allocated, previous tag if freed already) and the previous tag for the same slot. In the general case, MTE normally provides a 1/15 chance to bypass the protection if you don't statically reserve other tags. Dynamically reserving previous and adjacent random tags doesn't really weaken that.
It's unfortunate that MTE is only 4 bits rather than at least being 8 bits. 1/15 is much worse than 1/255. It could be larger. MTE paves the way for tagging with a larger number of bits, including via a future iteration of MTE with 8 bits or more supported.
It's not specifically a bug finding feature. You can build very useful deterministic exploit protections out of reserved tags, even by simply using the standard 0 reserved tag. 1/15 chance of catching memory corruption in the general case is also nothing to sneeze at especially when combined with other features. If an exploit uses both an arbitrary read vulnerability and then an arbitrary write vulnerability that's 2 opportunities to catch it. It also gets combined with other features which make those exploits less reliable and harder to write. It doesn't exist in isolation. In hardened_malloc, it's just one part of what it does, but it's a huge advancement for it. Tagging the subset of stack allocations with possible overflows or use-after-scope will be another huge step forward.
It would of course be much nicer having massive tags ruling out inter-object memory corruption nearly completely. That doesn't mean MTE is not a good exploit protection and only good for finding bugs. MTE is a lot stronger than most existing exploit mitigations like SSP. SSP provides probabilistic protection against stack buffer overflows by moving the safe variables to the other side and checking a canary on return. If the attacker can leak the canary which is global to the process in userspace, they can write that out as part of it. It also only works against linear or very small (simply by adding padding) overflows. It only has deterministic protection against certain types of C string overflows via a 0 byte if the libc puts one at the start of the canary.
Ideally, but it's not realistic to convince them to do that yet. It is very realistic to convince them to use asynchronous MTE for the base OS and their own apps. The more secure asymmetric MTE is a much harder sell, but would be way nicer for security.
MTE an CHERI use a similar approach but MTE doesn't have large enough tags to provide strong security in the general case. MTE can provide strong deterministic security properties through reserved tags. Anything not tagged has a 0 tag and anything tagged has a non-0 tag by default since it's a default exclusion. You can exclude other tags statically or dynamically via instructions for this, but you can also simply use the 0 tag for internal usage such as freed memory while knowing that any tagged pointer can't access it.
In hardened_malloc, we dynamically exclude the adjacent tags and previous tag used for an allocation slot. That provides deterministic protection against linear overflows and small overflows. For use-after-free, an access through a pointer to the freed allocation can't access it while freed or after being allocated again but rather needs to wait until the need time it's handed out again where there's a 1/15 chance it will have the right tag. This combines well with the other hardened_malloc security properties. It has FIFO/random quarantines for slab allocations and virtual memory, which delay reuse further and not deterministically. It avoids ever reusing memory locations between different allocation size classes until going above 128k, which are each in different regions with metadata all in another reserved region.
In the general case, MTE provides around a 1/15 chance for bypass due to currently only being 4 bits. It could be EASILY extended to support using 8 bits, and there are other free bits if you aren't using PAC. In theory, they could support up to 16-bit MTE for 48-bit address space or higher with a typical 39-bit address space. It's currently hard-wired to 4 bits which we've been told was chosen over 8 bits to enable storing the extra bits in ECC parity memory.
Much lower overhead, currently shipping, able to detect some forms of heap corruption but not nearly as reliably as CHERI. No protection on tags and small (2^4) space for them.
MTE can provide strong deterministic security properties through reserved tags. Anything not tagged has a 0 tag and anything tagged has a non-0 tag by default since it's a default exclusion. You can exclude other tags statically or dynamically via instructions for this, but you can also simply use the 0 tag for internal usage such as freed memory while knowing that any tagged pointer can't access it.
In hardened_malloc, we dynamically exclude the adjacent tags and previous tag used for an allocation slot. That provides deterministic protection against linear overflows and small overflows. For use-after-free, an access through a pointer to the freed allocation can't access it while freed or after being allocated again but rather needs to wait until the need time it's handed out again where there's a 1/15 chance it will have the right tag. This combines well with the other hardened_malloc security properties. It has FIFO/random quarantines for slab allocations and virtual memory, which delay reuse further and not deterministically. It avoids ever reusing memory locations between different allocation size classes until going above 128k, which are each in different regions with metadata all in another reserved region.
In the general case, MTE provides around a 1/15 chance for bypass due to currently only being 4 bits. It could be EASILY extended to support using 8 bits, and there are other free bits if you aren't using PAC. In theory, they could support up to 16-bit MTE for 48-bit address space or higher with a typical 39-bit address space. It's currently hard-wired to 4 bits which we've been told was chosen over 8 bits to enable storing the extra bits in ECC parity memory.
None of what you said is wrong but the point I was making largely centered around tags being architecturally visible, which is quite different from how CHERI operates.