why use ambient authority in genode hello world?

[Dan Connolly]

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?

[Norman Feske]

Hello Dan,

welcome to the mailing list!

Post by Dan Connolly
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
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

[Dan Connolly]

Post by Norman Feske
welcome to the mailing list!

Thanks! (Though I haven't actually subscribed yet.
I just noticed your reply by looking at the archives.)

Post by Norman Feske

... Why not pass a
capability to main ...?

That is a good point. In fact, we are currently revisiting the API in
https://github.com/genodelabs/genode/issues/1832

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.

Post by Norman Feske
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.