zlacker

>>zxombi+(OP)
On most current archs:

> Any piece of code running in a process can construct an integer value and, if this integer corresponds to a valid location in the process’ address space, then it can access memory at that location.

What this adds:

> CHERI changes this. Every load or store instruction and every instruction fetch must be authorized by an architectural capability.

So it should be possibly to call into any function (e.g. from an untrusted blob, and given the capabilities are set up) and on return have the guarantee that none of the callers memory has been touched and all the side effects are contained in the return value, and maybe selected whitelisted addresses?

I remember the mill architecture[1] also claims to have that capability, I think they called these calls "Portals". Btw the talks by Ivan Godard are a must watch if you have any interest in hardware architecture.

But how can existing code be just a recompile away from benefiting from these features, don't the capabilities have to be set up somehow (unless it is purely functional language)?

1: https://millcomputing.com/docs/

>>zeotro+LO
> Every load or store instruction and every instruction fetch must be authorized by an architectural capability.

This sounds great. But on the other hand ... Yikes! What if this tech falls into the hands of a big corporation and some manager needs a raise?

>>ameliu+op1
This isn’t a digital signature or anything like that. Instead, it’s increasing the size of pointers to include bounds and permission rights (R/W/X/etc), plus an extra tag stored somewhere else to prevent forgeries or mitigate corruption. So the only thing big corp gets out of this is software more resilient to memory corruption :-)