> leaving use-after-free/temporal memory unsafety on the table is a pretty conspicuous hole It's not a hole, it's just not addressed by CHERI explicitly. It's

> leaving use-after-free/temporal memory unsafety on the table is a pretty conspicuous hole It's not a hole, it's just not addressed by CHERI explicitly. It's like saying that ROP is a "hole" in NX - it's just not part of the NX threat model (well, it is/was, since they knew about it - but that is not the point). Yes, temporal safety is a concern. But removing spatial memory unsafety as an entire primitive will have consequences for practical exploitation of temporal vulnerabilities in some cases. A full exploit chain is often going to abuse both properties - though not always. But also, CHERI plays well with other mitigations, like MTE (which PAC is a precursor, I should have said MTE). MTE does address temporal safety. But a flaw is that it relies on pointer metadata that isn't protected against spatial unsafety. So CHERI reinforces that protection. The point being, removing spatial unsafety in the way that CHERI does (ie: enforced by hardware) will have significant impact across the board for security. Whether it plays out as well as I hope remains to be seen, but I think it would make practical exploitation of many temporal vulnerabilities more difficult. > it will be tough to sell moving to a new architecture as opposed to just using runtime mitigations on existing architectures (or, at the limit, rewriting the important bits in Rust). FWIW PAC is already deployed on every Android device afaik. I'd love to see everything rewritten in Rust but I'd still want CHERI.