In a 2 Dec twitter conversation https://twitter.com/GenodeLabs/status/671941252162678784, I was invited to elaborate here; so...
I wholeheartedly agree when the Genode book http://genode.org/documentation/genode-foundations-15-05.pdf says:
*Capability-based security* supposedly makes security easy to use by
providing an intuitive way to manage authority without the need for an all-encompassing and complex global system policy.
I don't understand why ignore this principle with the hello world code example:
#include <base/printf.h>
int main() { Genode::printf("Hello world\n"); return 0; }
Why appeal to ambient authority to print to the console? Why not pass a capability to main, as pony does with env https://github.com/CausalityLtd/ponyc/blob/master/packages/builtin/env.pony, capsicum at cap_enter() http://lwn.net/Articles/482858/, etc?
At lower levels of the architecture, genode has this structure; e.g. 3.5 component creation:
The environment is constructed by successively requesting the component’s
RM, RAM, CPU, and PD sessions from its parent.
Why not continue this structure in the base API?
Hello Dan,
welcome to the mailing list!
Why appeal to ambient authority to print to the console? Why not pass a capability to main, as pony does with env https://github.com/CausalityLtd/ponyc/blob/master/packages/builtin/env.pony, capsicum at cap_enter() http://lwn.net/Articles/482858/, etc?
At lower levels of the architecture, genode has this structure; e.g. 3.5 component creation:
The environment is constructed by successively requesting the component’s RM, RAM, CPU, and PD sessions from its parent.Why not continue this structure in the base API?
That is a good point. In fact, we are currently revisiting the API in this respect:
https://github.com/genodelabs/genode/issues/1832
With the new API in place, each component will be called with a reference to its environment. The global accessor 'Genode::env()' will eventually be removed.
That said, we will maintain the side effect of a default output facility (printf, PDBG) for practical reasons. For debugging (the main purpose of those functions), it would be unbearable to always need to pass a reference to a LOG interface around.
I suspect that your assumption of this output facility relying on "ambient authority" is slightly mistaken. There is _no_ single console in a Genode system to which each component magically would have the authority to write. The component startup code requests a LOG session for its default output from its parent. It is up to the parent to route this session request to a LOG server or not. The parent takes a deliberate decision. From the perspective of the component, the LOG session is just there. But the component does never know where the output goes. It has no (ambient) authority over anything the parent has not agreed on.
In contrast to the interfaces for dealing with the component's address-space layout, RAM session, or CPU session, I cannot see any benefit to be gained from hiding the default LOG session from arbitrary component code. What do you think would be the advantage of changing this part of the API?
Cheers Norman
Norman Feske writes 2016-01-25 07:52:10:
welcome to the mailing list!
Thanks! (Though I haven't actually subscribed yet. I just noticed your reply by looking at the archives.)
... Why not pass a capability to main ...?
That is a good point. In fact, we are currently revisiting the API in this respect:
Ah. Yes. Exactly: "In the spirit of capability-based security, let us drop the global env."
I hope the hello-world example is updated to make use of explicit access to the LOG session while you're at it.
That said, we will maintain the side effect of a default output facility (printf, PDBG) for practical reasons. For debugging (the main purpose of those functions), it would be unbearable to always need to pass a reference to a LOG interface around.
Yes, such a practical expedient is common in the ocap APIs that I'm familiar with; e.g.
The safeScope now provides a println-like traceln function for logging debugging output to the tracelog. This output is quoted using email quoting syntax, to identify the fully-qualified name of the module it came from. -- http://www.erights.org/download/0-9-1/highlights.html
But I guess I don't consider debugging/logging the main use of printf(). Traditionally, printf() (implicitly to stdout) creates the normal output of a program, not any sort of debug info.
-
Dan Connolly -
Norman Feske