Re: [ANNOUNCE] Introducing Codezero

olafBuddenhagen@xxxxxxx wrote:
> Hi,
>
> 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
> them.

> 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
> processes.

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...
>
> -antrik-

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.


Thanks,

--
Bahadir Balban