Checkpoint/restore of capabilities

[Norman Feske]

Hi Denis,

> The target application could create its own service with a root and 
> session Rpc_object and manage requests through an Entrypoint. Although 
> the Entrypoint creates new Capabilities through the PD session which the 
> Checkpoint/Restore intercepts (PD::alloc_rpc_cap). The 
> Checkpoint/Restore application cannot associate the created Capability 
> to a concrete Rpc_object which is created by the target application itself.

that is true. The monitoring component has no idea about the meaning of
RPC objects created internally within the child.

But the child never uses such capabilities to talk to the outside world.
If such a capability is created to provide a service to the outside
world (e.g., a session capability), your monitoring component will
actually get hold of it along with the information of its type. I.e.,
the child passes a root capability via the 'Parent::announce' RPC
function to the monitoring component, or the monitoring component
receives a session capability as a response of a 'Root::session' RPC
call (which specifies the name of the session type as argument).

Those capabilities are - strictly speaking - not needed to make the
child happy, but merely to enable someone else to use the child's
service. However, there is also the case where the child uses RPCs in a
component-local way. Even though the monitoring component does not need
to know the meaning behind those capabilities, it needs to replicate the
association of the component's internal RPC objects with the
corresponding kernel capabilities.

> To solve this problem I did not find any solutions which is transparent 
> to the target application nor is possible without modifying the kernel.
> A non-transparent, but user-level solution would be to let the 
> Checkpoint/Restore application implement the service of the target 
> application. But this will impose rewriting existing Genode components, 
> which I would avoid.
> 
> Perhaps someone in the Genode community has an idea, how I can get 
> access to the target application's Rpc_objects created by its own service.

This is indeed a tricky problem. I see two possible approaches:

1. Because the monitoring component is in control of the child's PD
   session (and thereby the region map of the child's address space), it
   may peek and poke in the virtual memory of the child (e.g., it may
   may attach a portion of the child's address space as a managed
   dataspace to its own region map). In particular, it could inspect
   and manipulate the child-local meta data for the child's capability
   space where it keeps the association between RPC object identities
   and kcap selectors. This approach would require the monitor to
   interpret the child's internal data structures, similar to what a
   debugger does.

2. We may let the child pro-actively propagate information about its
   capability space to the outside so that the monitoring component can
   conveniently intercept this information. E.g. as a rough idea, we
   could add a 'Pd_session::cap_space_dataspace' RPC function where a
   component can request a dataspace capability for a memory buffer
   where it reports the layout information of its capability space.
   This could happen internally in the base library. So it would be
   transparent for the application code.

   I think however that merely propagating information from the child
   may not be enough. You also may need a way to re-assign new RPC
   object identities to the capability space of the restored child.

Noux employs a mix of both approaches when forking a process. The parent
capability is poked directly into the address space of the new process
whereas all other capabilities are re-initialized locally in the child.
Maybe you could find a middle ground where the child component reports
just enough internal information (e.g., the pointer to its 'cap_map') to
let the monitor effectively apply the first approach (peeking and poking)?

Btw, just as a side remark, this problem does not exist on the base-hw
kernel where the RPC object identities are equal to the capability
selectors.

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