Hi Mark, great to get back in touch with you! I vividly remember visiting your group at OGI in 2005. Back then I presented my work on secure graphical user interfaces and you introduced me to the House project. Good times. :-)
> For example, Norman suggested using badging as a way to attach > server-local meaning to capabilities. But, as I understand the > API, the only capabilities that can carry a badge are those for > endpoints. A typical server receives requests from its clients > through a single endpoint, for example. But if different clients > use different capabilities for that endpoint, each with a distinct > badge, then the server will still be able to distinguish between > them: it just has to inspect the (unforgeable) badge value that is > delivered with each message. This is my understanding of how > badges work, but it doesn't allow for badges to be attached to > capabilities for other types of object (a thread, for example). This is consistent with my understanding. > A second detail has to do with the way that capabilities are > transferred via IPC. As I understand Norman's example, he is > imagining a situation in which capabilities might be passed freely > from F, to M, to C, and then perhaps back to M or on to other > recipients. But as I understand it, capability transfer via IPC > involves making a "derived" version of the capability in the > sender's cspace. [I'm looking, in particular at the language in > the 3rd bullet of Section 4.2.3 in the 1.3 API manual.] But: > > - Some capabilities cannot be derived at all (Table 3.2), which > would prevent F from sending them to M via IPC. > > - Other capabilities only allow a single level of deriving, > which might be enough for transmission from F to M, but could > prevent further IPC transfers. As far as I understand, the delegation of a capability (i.e., as IPC argument) does not imply a "derivation" in the sense of Figure 3.1. So the capability-derivation tree is not modified by delegating a capability via IPC. (this is different from the design of the L4 mapping database for memory mappings) After the delegation of a capability via IPC, a slot in the receiver's CSpace will simply refer to the same endpoint (and carry the same badge) as the capability that was specified as argument at the sender side. If this is the case, the delegation of capabilities (e.g., from F to M to C) can happen transitively without any problems. > The challenge here is for M to be able to access meta data for > capabilities that it has passed on from F to C. > > For starters, I'm imagining some kind of "registration" step that > initializes the connection between M and C. This process would > leave C with a badged endpoint for communicating with M, which > would provide a way for M to locate its meta data for C. I omitted this detail for brevity. In my example, C has already established a "session" to M, and M has already established a "session" to F. > In addition, this process would also establish a shared CNode > object, mapped in to the cspaces for both M and C. > Now, if C wants a new capability from M, then it chooses a > particular unused slot number (n, say) within the shared CNode, > and includes that number as part of its request to M. If M > approves the request and obtains the required capability from F, > it installs that capability in the specified slot, updates the > corresponding meta data, and returns control to C. Now C can use > the new capability, to whatever extent is permitted, without > having to go back to M. In fact C would even be able to delete > the capability by itself. However, for accounting purposes, we > would probably still expect C to send a message to M indicating > that the capability in slot n is no longer needed; this would also > trigger a further update of M's meta data for C. I think this > could be made to work even if C has deleted the capability or > moved it to another location in its cspace. For example, M might > hang on to the original capability elsewhere in its cspace > (outside the shared CNode), tracking the CPTR for that original > cap as part of the meta data for slot n. This would allow M to > perform operations on the underlying kernel object by using the > original capability, without having to assume that the derived > version is still in slot n. That is an interesting approach. C and M talk merely about plain session-local numbers. It seems to be somehow similar to the "hint" approach I mentioned in my previous email but it alleviates capability delegation via IPC. > Would something like this work? And Norman, would this (or > something like it) meet your needs? I cannot answer this question right away. The challenge would be to find a good way to hide this mechanism behind the generic Genode API. Thank you for chiming in and for the interesting idea of sharing entire CNodes (as opposed to delegating individual capabilities) between client and server. Cheers Norman -- Dr.-Ing. Norman Feske Genode Labs http://www.genode-labs.com · http://genode.org Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth _______________________________________________ Devel mailing list [email protected] https://sel4.systems/lists/listinfo/devel
