thread cancel_blocking usage, kernels

[Norman Feske]

Hi Steve,

thank you for the nice comment about the book!

> Arranging component relationships so that client and server correspond to
> a natural asymmetry of trustworthiness is sometimes straightforward, but
> sometimes ambiguous.  E.g. should one trust calls to a log service?

However the answer to this question might be, it should not be the
concern of the log client. The log client considers the log-session
interface as a contract. Since it got the session handed out by its
ultimately trusted parent, the client is not in the position to question
it anyway. If the log server misbehaves, the client is not responsible -
the parent is.

Consequently, the answer to the question comes down to a judgment of
risk by the integrator of the system scenario, not the implementor of
the log client.

> What
> if the log service gets upgraded to log to a network host that falls under
> control of an attacker? The attacker exploits a vulnerability and owns 
> the logger; some critical component then halts the next time it issues a
> logging call. Yes, you can e.g. redesign the logger as a client--I've done
> this, but it adds to the complexity of other components.

To counter this risk, one may insert a trusted component in-between the
log client and the network-facing "log streamer" component. E.g., by
directing the log messages via fs_log to a ram_fs component, the log
client only needs to trust those two low-complexity components. The log
streamer (which we assume to be easily compromised) would access the log
via a read-only file-system session from the ram_fs. It depends on the
ram_fs but the ram_fs does not depend on the on the log streamer. So
here, the ram_fs acts as a firewall between the log client and the network.

Btw, in practice, the log-over-the-network scenario raises further
questions. In particular, how to handle the case where the log data
fails to get out of the system? Should the system continue to operate
without capturing any trace of its behavior? Maybe it is preferable to
immediately stop, reboot, or fall back into a special fail-secure mode?
If the log client implemented defensive measures to deal with a
unresponsive log server, the client's implementation would implicitly
take a policy decision. But by making the liveliness of the log streamer
a responsibility of the common parent of both the log client and log
streamer, the parent is naturally in the position to take an explicit
and more educated policy decision. It is always good to have clear-cut
responsibilities.

> In some cases, RPC might not be the most natural communications solution.
> Is asynchronous message-passing (using only signals and shared memory)
> feasible in Genode?  Maybe something similar to "vchan" in Xen/Qubes.
> Perhaps this exists?

It exists in the form of the so-called "packet stream". For example, the
NIC session interface involves synchronous RPCs at session-creation time
but all network traffic flows through shared memory and signals. Section
3.6. "Inter-component communication" explains the different
inter-component communication patterns. The flavor you mentioned is
described in Section 3.6.6.

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