Trying to understand how capabilities are implemented

[Albin Otterhäll]

Hi Martin!

Sorry for the late reply, toke some time to get a mail client up and 
running with my mail provider. Didn't want to send a reply using their 
web client.

On 8/21/23 11:24, Martin Stein wrote:
> On 19.08.23 03:35, Albin Otterhäll wrote:
>> 1. The RPC object A is created inside the protection domain 1, which 
>> result in the object identity A being created by the kernel.
>>
>> 2. A has a name, which is a natural number.
>>     Q1: Is the RPC object's name the value of a class variable of type 
>> int?
> 
> In short: Yes, you can consider it a simple integer that is known to 
> both the kernel and the affected user-land program. The name references 
> this object only within this one program (respectively protection domain).
> 
> Just in case you're interested in some code background:
> 
> In header [1] you can find the classes Rpc_object and Rpc_entrypoint - a 
> thread that is used for handling RPCs on RPC objects. An RPC object 
> initially comes without a capability (the objects name), but a 
> capability is created and returned when linking the object via 
> Rpc_entrypoint::manage to an entrypoint. At this point the object 
> becomes ready to be called from outside the program.
> 
> As you can see in header [2], Capability has no members but inherits 
> from Untyped_capability, AKA Native_capability, which contains a pointer 
> _data. Now, this is where it becomes platform-specific. However, a very 
> simple case is the "base-hw" kernel. There, the _data pointer itself (as 
> long value) is used as local name of the object [4]. This long value is 
> the name that is registered in the domain's cap space inside the kernel 
> for that particular RPC object.

Thanks for the code references and the explanation!

>> 3. Protection domain 1 has a capability space insied the kernel.
>>     Q2: Is the protection domain seperate from the capability space in 
>> the kernel, and they're "connected" with some map somewhere?
> 
> In general, this is very kernel-specific. However, I know the internals 
> only for the "base-hw" kernel. In this kernel, the cap space is not 
> separate from its protection domain. Each domain object [5] contains a 
> tree _cap_tree of all RPC object names known to this domain (see [6] for 
> more details).

Okey! Didn't know that it could be different between the different 
kernels. Thought that they were abstracted out, but apparently not. :)

>>     Q3: Is the capability space a map between natural numbers and some 
>> form of address to the object identity? I.e. the map work similar to a 
>> set of OO references, there the keys are variable names; and the 
>> values are the memory addresses of object identities.
> 
> Again very kernel-specific and, again, my knowledge about "base-hw": In 
> this kernel your depiction is very accurate. Each RPC object name is an 
> Object_identity_reference in the kernel and contains a pointer 
> Object_identity *_identity.

Thanks for confirming!

>>     Q4: If the answer to Q3 is yes, does that mean that delegagion is 
>> some form of mechanism to share the adress of the object identity with 
>> other protection domains?
> 
> If I understand you correctly, yes and no. To the user it looks like 
> sharing an address in OO but you might better think of it as sharing the 
> _ability_ to access the object. In contrast to address sharing, 
> delegation creates a new local name/reference for the object identity in 
> the target domain/cap space. In my domain the object might be referenced 
> by the name "3" while in a domain I have delegated to, the object might 
> be referenced by the name "987". However, even if delegation would 
> result in the same name "3", the link between this name and the object 
> is unique to the target domain as is that between my "3" and the object. 
> This is well illustrated by § 3.1 Figure 3 in the book.

Is there a semantic difference between "sharing an address" and "sharing 
the ability to access the object"? I've looked at 
base/include/base/rpc_server.h and base/include/base/capability.h, but I 
couldn't see any parts about delegation (I don't have any experience 
with C++, so it's possible I've missed something obvious).

> I hope that was helpful!?

It was very helpful!

Thank you!
-- 
Albin Otterhäll