Re: [ANNOUNCE] Introducing Codezero

[Sam Mason]

On Wed, Jul 29, 2009 at 12:57:28PM +0300, Bahadir Balban wrote:
> Capabilities are an elegant way to achieve security. I am questioning,
> does it have to be object-based[1]? My worry is that things can get too
> complicated especially on a design such as a microkernel.
> 
> [1] By object-based I mean programmatically created objects being
> referred by remote clients.

Conceptually, no.  The ocap model just models the evolution of a graph
where the nodes are objects and the edges are capabilities.  The power
of the model is in its simplicity, the less distractions in the theory
(hopefully) means less problems in reality.

Practically, you can play whatever tricks you want--as long as the
resulting system is explainable in ocap terms.  This is similar to
modern (academic) programming languages, there is a small simple core
with a formally specified set of semantics and there's the sugar that
makes this code usable--ML or Haskell are good to look at here.  The
resulting system will tend to be much more reliable than one designed
the traditional way by bolting on bits where the needs demand.

> Sam Mason wrote:
> >  http://lists.gnu.org/archive/html/l4-hurd/2002-12/msg00003.html
> 
> For example this is a very generic example of how the protocols may get
> fairly complicated. The details are unimportant; it is chosen from your
> reference pretty randomly:
> 
> 1. Task A sends a message to S to initiate the reference passing operation.
>    Task A tells S which reference (O_A) it wants to move to which task
>    (B), and if it wants to synchronize with handle reception in B (flag
>    W for wait).  The server will return a transaction number T_A, which
>    is unique to a task, and makes a transaction record (O, A, T_A, B, W)
>    in the server.  Note: The transaction number has the same job as the
>    rendezvous port in auth.[1]

This is the problem of trying to get ocaps working in a system that
doesn't support them and is why it was decided that l4 was the wrong
place to be starting.  The above complications/problems vanish in a ocap
system.

> Now what's missing in this design? Two major concepts are capabilities,
> and distributed path navigation (i.e. in Codezero IO is multiplexed by a
> single file server instead). I am not yet sure what would be best on the
> latter issue.

Not quite sure what you mean by "distributed path navigation" but I
believe EROS had to divide up the path handling in non-intuitive ways to
get things running efficiently (i.e. faster than monolithic).  I don't
have a good reference, sorry.

> But getting back to capabilities, in my understanding a capability is
> just a structure that describes a resource as well as the security
> permissions on it and its owner.

No, a capability is *only* an unforgeable reference to an object.

Everything else, like security, drops out of this abstraction.  You
choose the implementation of the reference and to some extent the objects,
and from there you can determine what "unforgeable" practically means in
your system.  Unforgeable in a protected system is different to, say, a
crypto based ocap system.

-- 
  Sam  http://samason.me.uk/