Re: Capabilities, Anybody?

On 3/14/2024 7:37 AM, Theo Markettos wrote:

BGB <cr88192@gmail.com> wrote:

Presumably, in addition to the code, one needs some way for the code to
be able to access its own ".data" and ".bss" sections when called.

 AIUI you derive a capability from PCC (the PC capability) that gives you
access to your local 'captable', which then holds pointers to your other
objects.  The captable can be read-only but the capabilities inside it can
be writable (ie pointers allow you to write to your globals etc).
 

Some options:
    PC-relative:
      Unclear if valid in this case.
    GOT:
      Table of pointers to things, loaded somehow.
      One example here being the ELF FDPIC ABI.
    Reloading a Global Pointer via a lookup table accessed via itself.
      This is what my ABI uses...
>
I couldn't seem to find any technical descriptions of the CHERI/Morello
ABI. I had made a guess that it might work similar to FDPIC, as this
could be implemented without needing to use raw addresses (and seemed
like a "best fit").

 This is a description of the linkage model for CHERI MIPS; I'm not aware of
anything having changed significantly for RISC-V or Morello, although exact
usage of registers etc will be different.
 https://www.cl.cam.ac.uk/research/security/ctsrd/pdfs/20190113-cheri-linkage.pdf
 This also describes the OS-facing ABI on CheriBSD:
https://www.cl.cam.ac.uk/research/security/ctsrd/pdfs/201904-asplos-cheriabi.pdf
 

OK, cool.
I think I get it now:
You are using PC-rel within functions to load a capability to gain access to global variables.
This is admittedly a different approach than what I had guessed.
I guess this works (and is secure) so long as only the callee can load capabilities from within the region specified by the function-pointer capability, but the caller can not load capabilities from it.
Though, admittedly, this would be less directly applicable to my own system, where code and data sections are managed separately from each other (one shared copy of the .text section may have multiple task instances each with their own copies of the .data/.bss sections).
So, at least, in my case there would still be a potential weakness in being able to walk the global pointer. Seems I will need to think up a workaround.
Though, I guess one possibility could be to support a special-case instruction for GBR reloads.
In my ISA, with my existing ABI, it looks something like:
   MOV.Q  (GBR, 0), R18
   MOV    #Index, R0   //*
   MOV.Q  (R18, R0), R18
   MOV    R18, GBR
(*: There are more efficient ways to load an index, but this is what I had specified in the ABI. Could eliminate this constant load if the ABI allows using a jumbo-prefix here. )
In the 128-bit secure ABI, possibly something like:
   XMOV.X (R40, 0), R18
   MOV    #Index, R0
   XMOV.X (R18, R0), R40
(Say, with R40 taking over the role of the Global Pointer from GBR).
But, might be better, say, to repurpose GBR itself as the Global Pointer table:
   MOV.X (GBR, Disp33), R40 //*
( *: Here, will assume that any implementation capable of this mode, will also be able to support Jumbo prefixes... )
With (PC, Disp) and (GBR, Disp) loads being allowed, but most other use of the normal MOV.x instructions being disallowed. Similarly, GBR could become a read-only register in this mode.
If the programs can be disallowed from crafting their own machine-code, then it becomes possible to check these instructions at load-time.
Though, the global-pointer weakness would re-appear if the program is allowed to JIT compile stuff.
Though, this risk could be reduced by assigning the indices with random numbers (so, the program has no way of knowing which entry in the table belongs to which library, or which are valid and which are traps).
Well, at least, assuming the caller can't perform loads through function pointers, and then proceed to mine the offset from the function's prolog sequence.
I guess, this isn't perfect, but this would at least avoid needing to invent new mechanisms in the ISA.
...

Theo