Memory protection clarification.

[Daniel Waddington]

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

[Daniel Waddington]

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

Post by Daniel Waddington
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

[Norman Feske]

Hi Daniel,

thanks for taking the time for further investigation and for the nice
words about the book. :-)

Post by Daniel Waddington
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

[Daniel Waddington]

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

Post by Norman Feske
Hi Daniel,
thanks for taking the time for further investigation and for the nice
words about the book. :-)

Post by Daniel Waddington
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
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
https://lists.sourceforge.net/lists/listinfo/genode-main

[Norman Feske]

Hi Daniel,

Post by Daniel Waddington
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