Hacker News Reader

Comment by kibwen | Hacker News Reader

> We can't just fix the billion lines of C code out there by replacing it - we need strategies that wholesale destroy bug classes.

Won't any C code making use of int-to-pointer casts fail to work on CHERI? And isn't that a property of virtually every C codebase in existence? It sounds like that code will need to be rewritten either way.

> CHERI totally wrecks spatial memory unsafety. That's fucking huge. The death of buffer overflows.

You'll have to elaborate on what PAC is, but leaving use-after-free/temporal memory unsafety on the table is a pretty conspicuous hole. If the answer for that involves runtime overhead, then 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).

View on HN

No, as my article notes, because C has a dozen slightly different definitions for "integers that are basically pointers" they were able to keep size_t 64-bit and make intptr_t into a pointer-sized integer and mark it as something the compiler should manipulate as if it was 'void*' (because it is as far as CHERI is concerned). This is still a messy hack but it vaguely functions.

Rust doesn't have this luxury because it only defines an exact-pointer-sized integer, so it has to map usize to intptr_t and bloat up everything really badly.

'Gankra answers the cast part but for the other question: PAC is "pointer authentication codes", which is pretty much what it sounds like. It's a CFI+data integrity protection measure. Re: temporal memory safety, I don't think MTE solves everything but my understanding was you can revoke a capability for a region when the memory is freed and then mint it with a new one when allocating it out again, which would make stale pointers to it/UAF fault on access. Will have to check what the exact details are.

> 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.

Example:

> If we can find a legitimate user client that provides an implementation of getTargetAndTrapForIndex() that returns a pointer to an IOExternalTrap residing in writable memory, then all we have to do is replace trap->func with a PACIZA'd function pointer (that is, a pointer signed under APIAKey with context 0). That means only a partial PAC bypass, such as the ability to forge just PACIZA pointers, would be sufficient.

https://googleprojectzero.blogspot.com/2019/02/examining-poi...

How are you going to overwrite memory with CHERI? It cuts off a key primitive for bypassing PAC.

CHERI already has a working version of FreeBSD, so apparently not every C codebase in existence.

https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/cheri...

And plenty of other C and C++ software as well, if you follow those links.

Reply on news.ycombinator.com