[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [ANNOUNCE] Introducing Codezero

From: Bahadir Balban
Subject: Re: [ANNOUNCE] Introducing Codezero
Date: Sat, 25 Jul 2009 19:36:11 +0300
User-agent: Thunderbird (X11/20090608)

address@hidden wrote:

On Mon, Jul 13, 2009 at 10:47:37AM +0300, Bahadir Balban wrote:

I don't have a goal of implementing the ultimate microkernel desktop
system. My focus is on embedded systems.

Well, you certainly made your original post sound like if you believe
your work is compatible with the Hurd goals; but now you admit that it
actually isn't...

What I see in Hurd is a multi-server POSIX compatible OS core based
around a truly microkernel design. I accept certain lacking parts, but
by this definition my work is not that far from it. Especially that the
non-trivial OS services are there (memory management and file
management) its the protocol that lacks mostly on the Hurd design ideas,
i.e. distributed path navigation & a dynamic security mechanism.

But I can argue that L4 is the best candidate for a microkernel based
OS in general.

Not really. Shapiro has put it pretty well: one of the L4-based projects
(don't remember the name right now) showed that it *is* possible to
build such a system on top of L4 -- but only at prohibitive costs...

This confirms our own conclusions from the Hurd/L4 experiment:
implementing capabilities in user space on top of L4 requires a lot of
effort and introduces a lot of overhead.

This claim was probably made with many assumptions that narrowed down
the example case to produce a negative result. In other words, perhaps
the way it's design was anticipated was costly. I always think there can
be a new perspective.

Having all capabilities maintained by the microkernel will add policy to
it and inflate it, so it will somewhat deviate from a rigorous
microkernel design. If you believe that to be more appropriate for
maintaining security, it may be a reasonable tradeoff for you.

However, a significant goal in Codezero is to remain generic for
building any OS core on top. In that respect, no OS specific policy is
allowed inside. Keeping userspace capabilities in the kernel would be
against that principle.

I am currently implementing capabilities for kernel resources though.
That is a generic necessity and it makes sense to have it.

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.

This is not really realistic. For one, it allows for DoS attacks, unless
you can somehow guarantee that the resource usage of the validity check
is accounted to the client -- probably possible, but quite tricky.

OK I have thought about this, and actually you have a point that
checking in the kernel can be easily accounted to the client, since
kernel execution is also part of that thread's timeslice.

And then there is the overhead.

I am not sure about the overhead. If the service possesses a copy of the
capabilities to itself that its clients have, the checking is simply
done in the server in the form of a function that would otherwise be
placed in the kernel.

Capabilities would be sent to the server during mounting of the server
as a service or during open(). From that point on, each request is a
single call to the server.

But anyway before I get that far, I am currently implementing
capabilities for the microkernel resources, first.

EROS has proven that kernel-based capabilities can be implemented with
no noticable overhead... So this exercise is really pointless -- once we
have a capability-enabled kernel, there is no reason to avoid using

Lack of capabilities is not the only problem with traditional L4. The
purely synchronous IPC for example also turned out problematic, as well
as the fact that the kernel allocates memory on behalf of user

It is trivial to implement asynchronous messaging in L4, and I agree
that there are occasions where it is necessary. However, asynchronous
programming is a bad programming practice, and if you think of making it
a central part of your communication protocol this is a very very bad idea.

In latest L4 designs (and in Codezero) the kernel does not allocate for
userspace. I've implemented a complete pager with no relationship with
the kernel on memory usage.

Experience shows that microkernels are not really reusable, except for
systems with very similar requirements. The requirements of the Hurd are
very different from those of typical L4 use cases. Viengoos is partially
based on L4 ideas, but specifically designed to fit the requirements of
a system like the Hurd -- anything more similar to the traditional L4
will probably have some shortcomings for us...


From this discussion I see that the only major difference is managing
userspace capabilities inside the microkernel. I will look into that
option by adding a capability extension on the ipc request type. Each
ipc request number would be then subject to kernel's capability checking.

I am interested in Hurd because originally my idea of building a solid
microkernel-based OS closely relates to Hurd goals, even though some
design ideas seem to be different. Hopefully Codezero may provide a
viable alternative.


Bahadir Balban

reply via email to

[Prev in Thread] Current Thread [Next in Thread]