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:
- The RPC object A is created inside the protection domain 1, which
result in the object identity A being created by the kernel.
- 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!
- 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!
Hi Albin,
On 04.09.23 19:01, Albin Otterhäll wrote:
- 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. :)
At the level of Genode's Core component (the "root" component of the component tree) and Genode's base library (the basic environment for each Genode component) the differences between the kernels are indeed abstracted out. So, to every component other than Core capability management looks the same: Genode-like. However, as your question involved kernel internals, I wanted to mention that there are differences.
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).
A major difference is that, even if no one wants to provide you with the address to a local object, you can always guess the address and would thereby gain full access to that object. However, you would never be able to gain access to a remote object by guessing the correct local name, because _there is no local name_ for that object in your protection domain unless someone makes an appropriate delegation to you.
Cheers, Martin
-
Albin Otterhäll -
Martin Stein