Checkpoint/restore of capabilities

[Denis Huber]

Hello Norman,

thank you for the confirmation of my thoughts and for the 
correction/clarification of my misunderstandings.


> 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).


Thank you for the hint with the pointers inside an AVL tree. I did not 
thought my concept to the end and missed the fact, that the pointers are 
only valid inside target's address space. Thus, I will simplify the AVL 
tree for the cap map and the AVL tree of the object pool to lists. And 
just change the values of the list elements. I will still need to use 
the pointer of List::Element::_next, but I will have to convert the 
pointer to point to a dataspace of the target.


> 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.


Now I understand. You mean, I can propagate information from the target 
component through its capability space. For a simple example, I could 
create an (unbound) IPC gate, store a pointer into the label, and use a 
capability space slot to reference it. I could take one from the area 
controlled by core, which will (probably) not be overriden: I could take 
the last one which is 0x1ff.


> 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.


I could do the creation of the IPC gate and the assignment in the 
startup code of the application. I found a file, where a function 
initializes the main thread:

base_foc/src/lib/base/thread_bootstrap.cc:30

It is called prepare_init_main_thread. Is it save to use this function, 
or is there a better one?

What do you think about my approach? Will it work theoretically with the 
assumption that the last capability slot will not be used by any 
Genode/Fiasco.OC library and by no future library/component.


Kind regards,
Denis