(Among other tricks, 64-bit platforms don't actually use every bit in their address space, which means you can store things in the unused bits.)
ARM as in 32-bit arm already does this. If the lowest bit of the pointer is set to one when control jumps there it is treated as thumb (2 byte) instructions rather than A32 (4 byte) - that lower bit is still masked away of course.
The QARMA block cipher ARM proposes for PAC (but does not mandate, any can be used) "signs" (it isn't really signing, more like a mac but whatever) pointers with an authentication code as small as 3 bits.
That might sound nuts but a 3 bit code means you have 1/8 chance of bruteforcing correctly. Raise to the power of the number of required forged pointers and you can see how an exploit can be made very unreliable. E.g. if you need 4 forged pointers you now have (1/8)^4 chance of succeeding.
lol. We had 32-bit pointers on 386/486 systems in the early '90s, on systems with frequently less than 4MB of RAM.
If making pointers 4x bigger on systems with 2000x the amount of memory is a problem, I'm not sure how we're going to be able to solve anything ever again.
> Also, it confuses any code that assumes you can convert a pointer to a long (or long long) and back.
Well, that's why we invented intptr_t. Back in... checks notes C99. 25 years ago.
smh
Other than the temporal safety overheads-- which you could skil and still have spatial safety worth using-- the worst CHERI does is increase the memory bandwidth for pointers, so in a pathological case you might imagine a 2x slowdown.
In some cases it could make things faster and simpler though, since the CHERI approach can get process isolation without a MMU or TLB, so those overheads could be reduced or eliminated.
> Also, it confuses any code that assumes you can convert a pointer to a long (or long long) and back
such code is already pretty unportable on existing systems.
You can't implement an xor linked list on CHERI (at least not in the pure mode)... hardly seems like much of a loss. :)