genode manual

Norman Feske norman.feske at ...1...
Mon Apr 27 22:36:13 CEST 2015

Hi Prashanth,

On 04/27/2015 09:45 PM, Prashanth Mundkur wrote:
> Yes, this is a bit clearer.  Please correct me if I'm wrong, but I
> gather that:
> Since the server is in control over the lifetime of the RPC objects,
> it can destroy its RPC object (and hence invalidate the underlying
> capability) _at any time_ regardless of a request to close the RPC
> session.  In normal usage, however, the capabilities (or object
> identities) are destroyed as a result of closing the session, at the
> request of the client, server parent, or any node in the component
> tree that was involved in the creation of the session creation.
> This leads to the following question: can the server refuse to close a
> session?

yes, a server may ignore the session-close request. Servers that are
used by clients of different security levels (e.g., the nitpicker GUI
server that serves both untrusted clients and security-critical clients
at the same time) must be designed and implemented with special care.
Besides the correct response to session-close requests, another
consideration is the adherence to the security policy as configured by
the parent. The mere fact that a server is a child of its parent does
not imply that the parent won't need to trust it in some respects.

In cases where is not viable to trust the server (e.g., because the
server is based on ported software that is too complex for thorough
evaluation), certain security properties such as the effectiveness of
closing sessions could be enforced by a small (and thereby trustworthy)
intermediate server that sits in-between the real server and the client.
This intermediate server would then effectively wrap the server's
session interface.

> One minor typo I forgot to mention is
>     <any-service">
> in three places in the system_configuration.txt chapter.

Thank you!


Dr.-Ing. Norman Feske
Genode Labs ·

Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden
Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth

More information about the users mailing list