Hi Norman, The idea of passing the cap to identify metadata in a server that does not implement the object the cap refers to is problematic. I believe the operation you want at the kernel-level is "what is the index in my cspace corresponding to the cap I was sent". Given cspaces are arbitrary directed graph, this operation is asking what is the path between two points in the graph (if it exists) and not something we wish to support.
One approach is to have the mediator mediate all operations, i.e. have M as a proxy for access to F - obviously this has a performance impact. Alternatively, C gets a tuple (Fcap, Mdesc) and you split the interface - which is what you seem to be doing anyway. Given C will have already have session cap to M (lets call it Mcap), destroy involves invoking Mcap with Mdesc. Note: I'm glossing over interface enforcement, i.e. M gets Fcap1 which can destroy, and C gets Fcap2 which cannot, allowing you to enforce the split interface. Note: You could have an (Fcap2,Mcap)-like tuple to the client to split interface as well. In general, caps are more expensive and are only required when needing to pass an unforgeable authority between entities. Adding a descriptor to an existing session cap is generally cheaper. I know this statement is probably blasphemous, but performance implications of a design matter as long as the security model remains sound. Last design pattern is to implement object "death notification" from F -> M, which would require a registration protocol: M->F. We use this in RefOS for processes, which I assume are much more coarse-grained than your dataspaces. Note: We have mulled over the idea of an operation bool points_to_same_object(cap1,cap2), this would enable C passing a foreign cap (F) together with a handle to the metadata in M, and thus you could test if the passed cap corresponds with the cap associated with your metadata in M. I'd be interested if such an operation improve/eases the protocol design of interaction between your services. - Kevin -----Original Message----- From: Devel [mailto:[email protected]] On Behalf Of Norman Feske Sent: Friday, 7 November 2014 12:32 AM To: devel Subject: [seL4] Re-identification of capabilities Hello, I hope you don't mind me spamming the list with my problems. I have a question about the association of capabilities with process-local meta data. As far as I understand, the "badging" of capabilities is the recommended mechanism for servers to attach a server-local meaningful value to a capability. After having handed out the capability to a client, it gets this value reported each time the client (or any other process to which the capability was delegated to) invokes the capability or delegates the capability back to the server (e.g., as RPC argument). Now, I have the following scenario: There are three processes, a factory (F), a mediator (M), and a client (C). The factory is responsible for physically allocating objects (e.g., in Genode's case, one example would be the core process that hands out dataspaces). The mediator is a process that sits in-between the client and the factory (in the Genode world, this could the the init process). It keeps records about the allocation and may use this information to implement a policy. The client is the designated user of the object. To create an object, C will call M, which, in turn, will call F on behalf of C: alloc create F <-------- M <--------- C F will create the actual object and a corresponding badged capability and returns the badged capability as return value to M. Because M wants to keep records about the lifetime and parameters of the created objects, it needs to associate a process-local meta-data structure to the capability. badged cap F ---------> M C : (meta data <-> cap) M stores the meta data in a process-local data base using the cap as key. It then hands out the cap to the actual client. Sometime later, the client decides to destroy the object (or perform another operation at M that takes the cap as argument): badged cap F M ---------> C | | uses object (e.g., invoking the cap) destroy | (cap arg) | ? <----------+ When M receives the destroy request with the cap of the to-be-destroyed object as argument, it wants to look up the corresponding meta data from its data base. But unfortunately, the cap argument of the destroy function got assigned a new local name within M (some number within the receive window of M). How can M find the meta data associated with the allocated object? Best regards 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 ________________________________ The information in this e-mail may be confidential and subject to legal professional privilege and/or copyright. National ICT Australia Limited accepts no liability for any damage caused by this email or its attachments. _______________________________________________ Devel mailing list [email protected] https://sel4.systems/lists/listinfo/devel
