Re: Capabilities, Anybody?

On 3/12/2024 10:31 PM, Robert Finch wrote:

Can capabilities be applied to address ranges?
 Segmentation similar to the PowerPC 32-bit segmentation is being used in the current project. Where the upper address bits select a segment register which provides more address bits. I would like to use the same descriptors for capabilities and the address range segmentation.
 

Something like a segmentation scheme could also work.
Though, these seem like two different approaches, so there wouldn't be as much value in a shared descriptor. Segmentation also tends to be more coarse grained, rather than something applied to individual memory objects.
Of these two, I am left to suspect that segmented addressing may actually be the less painful of the two...
But, yeah, I was looking into a possible "Bounds Check Enforced" mode:
   Will require using XMOV.x instructions to access memory;
   Will check and enforce the use of tag bits.
     The tag bits will be ignored in the normal mode.
ISA level changes:
Will need a flag-bit, and a few more instructions for working with pointers / capabilities;
Will require a Tag-RAM area in DRAM.
If the enforced mode is not supported, probably setting this flag will be No-Op, and the Tag-RAM will not be used.
Micro-arch changes:
   Registers are extended from 64 to 66 bits;
   Load/Store operations also have 2 extra bits;
     Will only apply to 128-bit MOV.X and XMOV.X ops.
   Most operations will just set these bits to 0.
Unlike in the normal memory protection, handling of capability enforcement will be done in the EX-stage logic, rather than in the L1 cache.
Other effects:
ISR handling will now need to be more careful so as to not mess up the tag bits for registers (specifics TBD);
The role of GBR/GP will need to be moved over into a GPR.
May or may not consider making the register tag-bits accessible to privileged code as CR's, but this is likely to have a higher cost. The currently considered option is to have the ISR handler save the registers with MOV.X instructions and then copy the corresponding register tag bits out of Tag-RAM (and then restore these bits before restoring the registers), but this will be fiddly.
Thus far:
Of the parts added thus far, seems to have a fairly small impact on LUT budget.
As for whether or not this idea will be DOA, this is yet to be seen.
It requires effectively reviving the 128-bit ABI, which was also another likely DOA feature.
Only real incentive is for untrusted code, where security is more important than performance (and one can live with a world where integer->pointer casting is either not allowed or painfully slow, ...).
More likely, the use of optional bounds-checking with 64-bit pointers will remain as the more practical option, with the MMU and ACL checks serving as the primary security mechanisms.
...