Re: Capabilities, Anybody?

On 3/13/2024 5:37 PM, Robert Finch wrote:

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.
 

A capability effectively encodes 3 addresses:
   An upper bound, lower bound, and a target address.
A segment descriptor generally only needs two:
   A base address, and a size.
Similarly, segmentation often uses some sort of descriptor table, rather than large pointers. Though, some stuff I read implied that many capability machines were effectively handle based, encoding a capability as a combination of object handle and displacement. This is a different model (vs, say, trying to cram everything into a 128-bit pointer-like object).

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.
 

Possibly, but as noted, at 1/128 the RAM, for a 128MB RAM module, one needs 1MB of tag bits.
This is a bit more than one can reasonably keep entirely in Block-RAM, so it will be needed to back it out to main RAM.

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

Probably to later represent invalid values or similar.
The memory interface will only store 1 bit per 128-bits, but registers will have 2 bits per 64-bit register.
Partly this is to make it easier to verify if capabilities are still intact, when generally each part travels along a different 64-bit path.
For now:
   00: Data
   01: Capability
   10: Reserved / Not-a-Value
   11: Reserved

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.

In my case, the EX1/EX2/EX3 stages handle the pipeline facing parts of the memory interface, whereas the L1 cache deals with the actual load/store mechanism.
Bounds checking is handled in the AGU / AGEN logic, which is connected to the EX1 stage logic. It makes sense to handle capability access checks in the same area, since this logic can see the actual contents of the registers (the L1 D$ merely sees the target address).

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

Slowness is subject to interpretation.
On modern PC's, many people consider writing non-trivial programs in Python to be acceptable. But, compared to C, Python tends to be glacial.
Say, if a program is on-average 15-30% slower, this may be acceptable.
However, 5x slower would likely not be acceptable.
The main overheads of capabilities in my case being likely:
   Memory overhead due to bigger pointers;
     Likely to effect things like cache misses, etc.
   Suddenly nearly everything takes twice as many registers;
     So, it is like the register set got cut in half.
   The memory ops now have smaller displacements:
     MOV.x has Disp9u / Disp10s
     XMOV.x has Disp5u / Disp6s
   Integer to pointer casts will have a significant overhead;
   The XMOV.x ops will be scalar only.
   ...
With the prior bounds-check support (in the 64-bit ABI), there was around a 10% overhead, but this was with 64-bit pointers and mostly still leveraging the existing ISA where possible.
I am guessing Bounds-Check-Enforce is more likely to have around a 30% overhead, maybe more or less. But, this is likely also to be for code that is potentially hostile. But, then, one wants the security to be strong enough that there is no practical way for code to break out of the sandbox; though, if allowing for arbitrary machine code, then there is still the great potential Achilles heel that is the Global Pointer or GOT. Only sure way to avoid this is to not have any "potentially compromising" capabilities anywhere within the graph of what is reachable from the hostile code, and the main obvious way to do this is via the use of system call.
If operating solely at the C level, it is a little easier: One needs to make sure that there is no way for the code to get direct access to the Global Pointer or GOT or similar. An ABI based on FDPIC would be bad here, since it is within the reach of C code (under typical C behavior, UB notwithstanding) to be able to gain access to the GOT for an arbitrary function pointer.
A big chunk of this would be overhead shared with the 128-bit ABI (which would have gone over entirely to 128-bit bounds-checked pointers), with a few new/additional overheads.
For things like network-stack code, it is more likely to be sufficient to use the normal (non-enforced) bounds-checks.
As for whether it makes sense to support the relative expense of tagged memory for a niche edge case, I don't know.

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

 

In other news:
The frustrating bug I had been hunting, seemingly turned out to not have been a CPU core bug, rather:
BGBCC was apparently doing something invalid (likely manifesting somewhere in "printf()");
Then, "printf()" was stomping registers in the caller;
Some debugging attempts were essentially moving the bug around.
The exact results of the stomped register also seemed to be variable (so it would manifest differently depending on the specific situation and prior memory contents).
Though, as of yet, it has not been localized to a specific instruction or usage pattern (only, that some of the logic for special-case handling of variable/register assignment for things like function return values was seemingly somehow causing printf() to stomp some of the callee-save registers, but only sometimes). Disabling this feature apparently :fixing" the bug.
More looking into this is likely needed.
...