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