3 ms·

The overhead of 128-bit pointers is a pretty big downside, I'd imagine, especially with only 8 GB of RAM on some models. Also, it confuses any code that assumes

The overhead of 128-bit pointers is a pretty big downside, I'd imagine, especially with only 8 GB of RAM on some models. Also, it confuses any code that assumes you can convert a pointer to a long (or long long) and back.

jazzyjackson 2y ago
this is above my head but just wanted to mention that apple m chips have 128bit registers, tho I don't know if that means anything wrt the overhead
- LegionMammal978 2y ago
  I mean the extra 8 bytes of RAM per pointer, every time you store an object in memory that refers to another object, or that points to a vtable. No amount of register size will get around that.
- saagarjha 2y ago
  You will note that they have fewer of those and expose them in much more limited ways.
astrange 2y ago
ARM's features like PAC/MTE that descend from CHERI don't use 128-bit pointers. (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.)
- zahllos 2y ago
  Correct. In fact since memory access must be aligned (I think Linux uses 4 byte alignment, which is the alignment of instructions) the lower bits of every code pointer can be used for this purpose. 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.
Karellen 2y ago
> only 8GB of RAM 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
nullc 2y ago
plenty of applications would be just fine with a 5x slowdown vs state of the art CPUs and could desperately use the security improvement. 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. :)

jazzyjackson 2y ago

this is above my head but just wanted to mention that apple m chips have 128bit registers, tho I don't know if that means anything wrt the overhead

LegionMammal978 2y ago
I mean the extra 8 bytes of RAM per pointer, every time you store an object in memory that refers to another object, or that points to a vtable. No amount of register size will get around that.
saagarjha 2y ago
You will note that they have fewer of those and expose them in much more limited ways.

astrange 2y ago

ARM's features like PAC/MTE that descend from CHERI don't use 128-bit pointers. (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.)

zahllos 2y ago
Correct. In fact since memory access must be aligned (I think Linux uses 4 byte alignment, which is the alignment of instructions) the lower bits of every code pointer can be used for this purpose. 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.

Karellen 2y ago

> only 8GB of RAM 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

nullc 2y ago

plenty of applications would be just fine with a 5x slowdown vs state of the art CPUs and could desperately use the security improvement. 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. :)