Re: [ANNOUNCE] Introducing Codezero

Sam Mason wrote:
> I keep getting the feeling that you've "missed" the point of
> object-capability systems.  I'd recommend a read through the literature
> available on it, say:
>
>   http://www.erights.org/
>   http://www.eros-os.org/
>   http://www.cap-lore.com/

I've read them already to a certain extent. The problem is that the hurd
project is taken into object-capability grounds completely. This is fine
as one perspective. But I am questioning, does it really *have* to be
this way?

> Marcus and others (sorry for minimizing everyone else, it was Marcus
> who was most vocal when I joined) tried *very* hard to make a l4 work;
> maybe a fresh perspective was all that was needed, but it looked pretty
> terminal at the time to most people.  I've had a look back through the

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.

> archives and the following looks like a nice early reference:
>
>   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]


There are handles, references being passed, transaction ids, etc. This
won't work. The protocol will get extremely complicated, and you give an
opportunity to monolithic kernel people to despise your design.

Things should be kept very minimalistic. You should always keep in mind
that you are competing against mere function calls in a monolithic kernel.

Generally speaking, whatever you have inside a monolithic kernel, should
be moved to userspace, being carefully divided into multiple servers.
When you do the division, each individual server should maintain a
portion of the kernel state of a process that would otherwise be kept in
a single structure in a monolithic system. Then, you need to make them
coordinate properly (and synchronously) to serve incoming requests.
That's all you need for your first version.

Monolithic people say it gets very complicated to debug the
communication. I very rarely ran into such problems. I am confidently
speaking about it because I have done this to a certain extent. A design
such as above, together with synchronous communication feels like you
are developing on a monolithic 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.

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. It's a compact, elegant description of
resource  accessibility that can be dynamically passed around. Could it
be used as a central mechanism to access programmatically created
objects? Yes. But it doesn't have to be. Using the compact definition I
just used, it is powerful enough to build all the secure communication
that a microkernel needs. IOW I am suggesting to drop objects, and use
capabilities to secure ad-hoc services and resources.

> Jonathan Shapiro, of EROS and Coyotos, seemed to join properly here:
>
>   http://lists.gnu.org/archive/html/l4-hurd/2005-09/msg00060.html
>
> and the earliest I could find was:
>
>   http://lists.gnu.org/archive/html/l4-hurd/2003-08/msg00000.html
>
>
> The cap-talk mailing list is active and I'm sure would welcome any
> questions you may have:
>
>   http://www.eros-os.org/mailman/listinfo/cap-talk

I will certainly look into them for improving on my understanding of
capabilities.

Currently I am currently finishing off with kernel capabilities on
Codezero. Next on my agenda:

1.) Demonstrate kernel capabilities in userspace servers mm0/fs0 (e.g.
thread, space creation, manipulation, ipc etc.)

2.) Extend ipc capability mechanism to include ipc request numbers,
either in userspace or as a kernel extension, so that all ipc-based
requests can be covered by capabilities. (e.g. Think of IDL as opposed
to just request numbers to servers, and compare which is more heavy-weight).


Thanks,

--
Bahadir Balban