genode manual
Prashanth Mundkur
pmundkur.l4 at ...9...
Mon Apr 27 21:45:06 CEST 2015
Hi Norman,
> Btw, I updated the PDF today:
>
> http://genode.org/files/53bcb8e33fe6602fed25edc3c7b922c5/manual-2015-04-27.pdf
Thanks for the update!
> The revocation of capabilities is briefly covered at the end of Section
> 3.1.2. I agree that it would be useful to elaborate it a bit more in
> Section 3.2.4. Would the following description be of help?
>
> The object identity of a session RPC object (and further RPC objects
> that may have been created using the session) is owned by the server. So
> the server is in control over the lifetime of those RPC objects. When
> the server is instructed by its parent to close a given session, the
> object identity of the session vanishes. Since capabilities become
> invalid (aka revoked) once their associated RPC object is destroyed, the
> revocation of capabilities is a side effect of the closing of sessions.
> The closing of a session can naturally be initiated by all nodes of the
> component tree that were involved in the session creation.
>
> In practice, the partial revocation of authority is rare. Revocation of
> authority is usually performed by destroying the sub system, from which
> authority must be revoked.
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?
> > - 3.6.1: Synchronous RPC
> >
> > This is not clear: "Each IPC server has a corresponding untyped
> > capability that can be used to perform calls to the server using an
> > IPC client object." Perhaps server/client got swapped somewhere?
>
> This is indeed a bit confusing. Does it become more clear if I reword it
> as follows? "For each IPC server, there exists an associated untyped
> capability that is created with the IPC server object. This capability
> and can be combined with an IPC client object to perform calls to the
> IPC server."
Much clearer, thanks!
One minor typo I forgot to mention is
<any-service">
in three places in the system_configuration.txt chapter.
Thanks,
--prashanth
More information about the users
mailing list