Re: Capabilities, Anybody?

On 2024-03-13 2:29 p.m., BGB wrote:

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.
 

Segmentation and capabilities look similar to me. They both have base / bounds and permissions / access rights. The difference is the capability carries along the pointer value and a segment descriptor does not. There is the object type too, more specific than just code or data.

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.

One thought I had was to use whole bytes instead of just a tag bit. That would make tag "bits" accessible with regular load and store instructions. But also had considered using a second bit to indicate a pointer store for garbage collection. If using one bit, why not use two?
One BRAM can handle a lot of tag bits.

 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.
 

What is the second extra bit for?

Unlike in the normal memory protection, handling of capability enforcement will be done in the EX-stage logic, rather than in the L1 cache.

Hm, I was going to handle capabilities in the MEM stage logic.

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

In the document IIRC they said performance was an issue for capabilities in the past. Implying maybe that with the performance of a modern machine it may not be as painfully slow. Having an MMU was painfully slow too, adding a clock cycle onto all the memory access.

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