Checkpoint/restore of capabilities

Norman Feske norman.feske at ...1...
Wed Aug 31 18:43:43 CEST 2016

Hello Denis,

> After a restore of a component the capability space shall be the "same" 
> as before the checkpoint:
> 1) The capabilities after the restore shall point to corresponding 
> object identities.
> 2) Also the capabilities after the restore shall be on the same slot 
> (have the same address) in the capability space as before the checkpoint.
> The capability space resides in the kernel and Genode does not offer an 
> API to manipulate it. Is there a way to accomplish my goal with Genode's 
> API anyway?

there is no ready-to-use solution via the Genode API because the way
capabilities are handled vastly differs between the various kernels.
Manipulating the capability space of a remote component wouldn't even be
possible on some kernels. However, since you are using a specific kernel
(Fiasco.OC) that provides an asynchronous map operation, the problem can
be tackled in a kernel-specific way.

I would propose to extend the existing 'Foc_native_pd' RPC interface [1]
with RPC functions for requesting and installing capabilities from/into
the capability space of the PD.


The function for requesting a capability would have an iterator-like
interface that allows the client to iterate over the PD-local selector
numbers and sequentially obtain the underlying capabilities as
Genode::Native_capability objects (which can be delegated via RPC). Each
call would return a Genode::Native_capability and a selector number of
the capability to request with the next RPC call. In a first version,
you may simply iterate over all numbers up to the maximum selector
number, returning invalid capabilities for unused selectors. The
iterator-like interface would then be a performance optimization.

The function for installing a capability would take a
Genode::Native_capability and the destination selector number as
arguments. The implementation of the 'Foc_native_pd' interface resides
in core, which has access to all capabilities. The implementation would
directly issue Fiasco.OC system calls (most likely 'l4_task_map') to
install the given capability into the targeted PD.

Does this sound like a reasonable plan?


Dr.-Ing. Norman Feske
Genode Labs ·

Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden
Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth

More information about the users mailing list