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 _______________________________________________ Genode users mailing list [email protected] https://lists.genode.org/listinfo/users
