Hi,
If an application allocates memory from its parent (e.g., from init) - is this memory capability granted or mapped? Assuming a secure kernel and IOMMU, how secure is this memory from access by other processes or the root process? How is memory clean up after application exit/death?
(Sorry for the newbie questions, I have some catching up to do).
Daniel
Apologies for spamming the list - the answers to my questions are all in the *marvelous* Genode book -- http://genode.org/documentation/genode-foundations-15-05.pdf
Delegation is mapped not granted and core retains capabilities for all resources (and does the book-keeping of course).
When a child is destructed the resources go back to the parent.
One thing though that is not clear to me, is that if a child dies and is not cleanly destroyed, do the resources get lost?
Daniel
On Mon, Mar 28, 2016 at 3:39 PM, Daniel Waddington <waddy16925@...9...> wrote:
Hi,
If an application allocates memory from its parent (e.g., from init) - is this memory capability granted or mapped? Assuming a secure kernel and IOMMU, how secure is this memory from access by other processes or the root process? How is memory clean up after application exit/death?
(Sorry for the newbie questions, I have some catching up to do).
Daniel
Hi Daniel,
thanks for taking the time for further investigation and for the nice words about the book. :-)
One thing though that is not clear to me, is that if a child dies and is not cleanly destroyed, do the resources get lost?
A child is destroyed by the parent by closing all open sessions of the child in the reverse order of the session creation. At the very end, the parent closes the child's RAM session, which has the effect of transferring the child's remaining RAM quota to the registered reference account (which is usually the parent's RAM session). In other words: Regardless of how the child behaves, the parent is always able to regain the resources by closing the child's sessions and transferring the session quotas to itself.
Does that answer you question?
Cheers Norman
So in a "resilient" system the parent would need to have the responsibility of checking the liveness (e.g., in event of fault) of the child to see if the resources should be taken back?
Daniel
On Tue, Mar 29, 2016 at 9:53 AM, Norman Feske <norman.feske@...1...> wrote:
Hi Daniel,
thanks for taking the time for further investigation and for the nice words about the book. :-)
One thing though that is not clear to me, is that if a child dies and is not cleanly destroyed, do the resources get lost?
A child is destroyed by the parent by closing all open sessions of the child in the reverse order of the session creation. At the very end, the parent closes the child's RAM session, which has the effect of transferring the child's remaining RAM quota to the registered reference account (which is usually the parent's RAM session). In other words: Regardless of how the child behaves, the parent is always able to regain the resources by closing the child's sessions and transferring the session quotas to itself.
Does that answer you question?
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
Transform Data into Opportunity. Accelerate data analysis in your applications with Intel Data Analytics Acceleration Library. Click to learn more. http://pubads.g.doubleclick.net/gampad/clk?id=278785471&iu=/4140 _______________________________________________ genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
Hi Daniel,
So in a "resilient" system the parent would need to have the responsibility of checking the liveness (e.g., in event of fault) of the child to see if the resources should be taken back?
yes, that would work. The remaining open question is how to detect lifeness. In principle, this could be done by the child providing reports (via a 'Report' session) about its internal state in a periodic fashion - similar to a watchdog timer. If the child stops reporting, or if the reports start to look strange, it may be in trouble.
Another principal (yet untested) approach would be the use of core's TRACE mechanism, which allows a trace monitor to dynamically instrument components at interesting points like RPC calls or the reception of signals. If the trace monitor has a model of the component's behavior, it may match the traces against the model.
Cheers Norman
-
Daniel Waddington -
Norman Feske