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 ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot _______________________________________________ genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
