Re: [ANNOUNCE] Introducing Codezero

olafBuddenhagen@xxxxxxx wrote:
> Hi,
>
> On Wed, Jul 01, 2009 at 10:10:25AM +0300, Bahadir Balban wrote:
> > Bas Wijnen wrote:
>
> > Implementing fine-grained access control mechanism inside the
> > microkernel should take no more than a week or two. I would imagine
> > all I would need to do for the first version is to add a per-thread
> > bitmap structure that controls resources such as the amount of
> > virtual/physical memory, cpu time, with whom the communication is
> > allowed, which requests, what type of ipc ... etc.
>
> Isn't most of that actually possible with standard L4?...

Yes, particularly secure L4 provides a security layer on top of the base
L4 design.

So you may ask, why re-do it and split efforts? Well, even though
similar mechanisms are incorporated, I argue that my implementation is
simpler, cleaner and with well-structured components. I will perhaps
leave the comparison discussion to a separate email.


> However, this is *not* sufficient. Sure, it is fine for embedded
> systems, which live in a very statical environment. It has been done
> before -- a number of multiserver systems exist that are quite
> successful in the embedded market.
>
> However, for a general-purpose operating system, we need much more
> dynamic permission and resource management. This is where the real
> problems lie -- the major challange we face with the Hurd; and in fact
> the major challenge in any attempt to create a general-purpose
> multiserver operating system.
>
> -antrik-

By adding limits I did not try to mean a static environment. You should
have limits for resource usage at all times, even if those limits can
dynamically change.

Dynamic resource management is certainly important. My current plan is
to first implement a compact capability system for in-kernel resources.
Then this is going to be extended such that dynamic userspace resource
ownership and management can be supported.

I don't have a goal of implementing the ultimate microkernel desktop
system. My focus is on embedded systems. But I can argue that L4 is the
best candidate for a microkernel based OS in general. The reason is
simple. L4 is very well engineered. It provides the leanest mechanisms
that are made available by the underlying hardware. You can build up
anything on top of it. Security systems, Object-based capability
systems, distributed systems, etc. in my view it's all a matter of
writing the relevant C code on top.

I have a few things in mind for security. After I incorporate a compact
capability system inside the microkernel, I will work on extending it to
userspace:

/*
  * Defines a resource and access rights
  * to access it in a uniquely identified
  * capability structure.
  */
struct capability {
        l4id_t capid;           /* Unique capability ID */
        l4id_t resource; /* Thread, space, ipc, memory, cpu etc. */
        l4id_t owner;           /* Owner thread */
        u32 access;             /* Permitted operations bitmap */

        /* Limits on the resource */
        unsigned long start;    /* Resource start value */
        unsigned long end;      /* Resource end value */
        unsigned long size;     /* Resource size */
};


For example something like above may be used for implementing
capabilities in userspace. Perhaps a type field is yet to be added.

The protocol could be as follows:
A user program is granted a capability as above from an authorization
server. The capability is most likely one that allows communication with
a service. The service obtains a copy of this capability from the auth
server, and whenever the user program calls the server (it also has an
ipc capability to it) the server checks the request from its capid, and
either accepts or refuses to take it. So capability validity checking is
distributed to those resources that are involved in the capability.

It seems like in a simple model as above, you can dynamically pass along
capabilities, check for capability validity, and yet, the microkernel is
free of any of this burden, such that, say, a set of lightweight,
no-capability, threads may run in isolation in a separate L4 domain
without having a clue of what's going on on the other side. (Let's say
we have a separate DSP processor that needs an efficient multi-threaded
driver that needs to communicate with nobody)

As a last note, the above description is just a small example that may
not have the answer to all resource management problems. But it can be
improved and it models how things can be done in userspace on top of L4.
I don't particularly see a necessity for writing a completely new
microkernel with the argument that L4 cannot incorporate capabilities.

Thanks,

--
Bahadir Balban