Checkpoint/restore of capabilities

[Norman Feske]

Hi Denis,

> I created a simple figure [1] to illustrate my thoughts. [...]
> 
> [1] 
> https://github.com/702nADOS/genode-CheckpointRestore-SharedMemory/blob/b78f529818d01b42f0b35845e36e4e1d08b22eba/drawio_genode_capability_foc.png

the figure is good except for the detail that the capability map should
appear within the protection domain. It is a component-local data structure.

> In order to restore a component on another ECU, the checkpointed 
> variables representing capabilities (entries in memory, e.g. stack) have 
> to be made valid. Therefore, I have to restore the IPC gate, the 
> capability space slot pointing to this IPC gate, and allocate a new 
> badge, because it is valid only in one system and the component is 
> migrated to another system. Also, I have to restore the capability map 
> slot to point to the new badge and restore the RPC object.

Exactly.

> In the following I assume that the RPC objects of the target component 
> are created by the Checkpoint/Restore component (i.e. it intercepts the 
> session requests and provides own sessions at child creation). The other 
> case regarding local RPC objects of the target component will be 
> discussed later, if I hopefully have the time:
> 
> By virtualizing the session RPC objects and the normal RPC objects, I 
> can checkpoint the state of them. Thus, I can recreate an RPC object. 

I do not completely understand what you mean by "virtualizing RPC
objects". To recap the terminology, an RPC object is a data structure
that is local to the component. When restoring the virtual address space
of the component, this data structure gets re-created automatically.
However the data structure contains the capability (it is an
'Object_pool::Entry') as a member. The "local name" aka "badge" of this
capability is used as a key to look up the invoked object of an incoming
RPC request. This capability originated from 'Pd_session::alloc_rpc_cap'.

> When I do that the RPC object has a new capability (local to the 
> Checkpoint/Restore component) and a valid badge. Implicitly a valid IPC 
> gate is also recreated. Thus, the target component has to know this 
> capability inside its protection domain. Therefore, the capability 
> space/map slot has to point to the IPC gate or to the new badge, 
> respectively.
> * The capability space slot is recreated by issuing l4_task_map to map a 
> capability from core to the target child. This is done by extending 
> Foc_native_pd interface (see in an earlier mail from Norman).
> * The capability map slot is recreated by 
> Capability_map::insert(new_badge, old_kcap). Thus, I have to checkpoint 
> the kcap by Capability_map::find(new_badge)->kcap().

Yes. The problem is that the latter operation is a component-local
manipulation of its cap map data structure. The monitor cannot call the
 function in the target's address space directly.

> Now I am missing the pointer to target component's internal capability 
> map.
>
> I already have all dataspace capabilities which are attached to the
> target's address space. With the pointer I can cast it to a 
> Capability_map* and use its methods to manipulate the Avl-tree. Please 
> correct me if I am wrong.

This won't work that easily. The AVL tree contains pointers that point
to some place within the target's address space. A function call would
ultimately de-reference those pointers. If you attach (a part of) the
target's address space within the monitor's address space, the pointers
would generally not be valid in the monitor's address space. Aside from
that, I do not think that it would be a good idea to let the monitor
de-reference pointer values originating from the (untrusted) target.

The AVL tree must be manipulated without relying on the original code.
To sidestep this issue, I proposed to simplify the data structure, e.g.,
by replacing the AVL tree by a list. Then, the monitor just needs to
write new badge values into the targets memory but won't need to
manipulate the target's data structures. This applies to the AVL tree
used in the cap map and the AVL tree used by the object pool (which also
uses the badge as key).

Granted, by using a plain list, the lookup becomes slower. But you
remove a show stopper for your actual research goal. Once, the
checkpointing works, we can still try to solve the AVL tree problem.

> Norman, you proposed a rough idea of how to obtain a dataspace 
> capability of the capability map through the PD_session in one of your 
> previous mails:
> 
> On 07.10.2016 09:48, Norman Feske wrote:
>  >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.
> 
> Can you or of course anyone else elaborate on how it "could happen 
> internally in the base library"? Does core know the locations of 
> capability maps of other components?

No. But my suggestion of the PD-session extension was not concerned with
capability maps at all. The proposed mechanism would only operate on the
target's capability space. The capability map must by adjusted by the
monitor by manipulating the target's memory. Both pieces of the puzzle
are needed: the population of the target's cap space (via an interface
provided by core), and the update of the badges in the target's cap map.

By "could happen internally in the base library", I meant that the
proactive "leaking" of interesting information (like the base address of
the cap map, or the association between kcap selectors and badges) from
the target to the monitor could be hidden in the base library (which is
locally linked to each component). Because it would not be visible at
the API level, it is transparent to component developers.

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