Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: BGB <cr88192@gmail.com>
Newsgroups: comp.arch
Subject: Re: Capabilities, Anybody?
Date: Thu, 14 Mar 2024 12:08:12 -0500
Organization: A noiseless patient Spider
Lines: 110
Message-ID: <usvb0b$1o6gl$1@dont-email.me>
References: <usg40i$1udfo$3@dont-email.me>
 <1951488caf6138e90c4bac62ee6ac41d@www.novabbs.org>
 <_Y_GN.75295$LONb.13164@fx08.iad> <usibg4$2ffdn$1@dont-email.me>
 <Rry*0u3Ez@news.chiark.greenend.org.uk> <usm15j$3e8ct$1@dont-email.me>
 <0rF*JVlFz@news.chiark.greenend.org.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Thu, 14 Mar 2024 17:09:31 -0000 (UTC)
Injection-Info: dont-email.me; posting-host="e246796ede20208964964aa8d7229656";
	logging-data="1841685"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18Jfn1662sKj1LE5QEzequrUTaynCX9exk="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:RgNDNAYc68yd93crwizGB1Bjvug=
In-Reply-To: <0rF*JVlFz@news.chiark.greenend.org.uk>
Content-Language: en-US
Bytes: 5445

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