[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: Wed, 01 Jul 2009 10:10:25 +0300
User-agent: Thunderbird (X11/20090318)

Bas Wijnen wrote:

I'm not sure if "adding capabilities" to a working system is a proper
way to get security right.  Security is not something that can be added
to a program.  It must be at the core, and the design must support it
from the start.

If you try to add it, I fear that either it will not work, because there
are insecure bypasses for secure parts, or it will have bad performance
because the fast paths of the system aren't used, or both.

Hi Bas,

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.

Securing the existing communication may take some effort, although it
should not be too difficult. There are only 2 servers and a handful of
requests. I think I will have part of the above implemented on the next
version of Codezero. It should also be possible to pass along
capabilities dynamically, though I would imagine most security
permissions to be set up during initialization.

What I've seen from capability systems, they can be seen by object
oriented systems as remote object calls.  However, this is not enforced
in any way.  The kernel just sends a message over a protected channel.
How this is used or interpreted by both ends of the channel is their

In my plan, there will be servers, (i.e. C programs) that simply do IPC
in a controlled fashion. The design won't be centered around
interface/implementation type of remote object instantiation as you would see in say, Corba, Java RMI etc. This is because the goal is to reduce interfaces down to a minimum generic set of calls such as open/close/read/write ... just like in Plan 9. So instead of having a different interface for each object, there will simply be a file-based interface for everything.

Turning a capability-based system into something like Linux is easy[1]:
just build a central file system server and give a capability for it to
all processes.  Turning Linux into a capability-based system is
equivalent to rewriting Linux.

Yes sure. Although I envision that in a new capability system, most capability management can be done during the mounting of a new service on a process namespace. Correct me if I am wrong.

FS0 has the VFS and the underlying filesystems bundled.

In one server?  Does that mean that a new FS0 is needed to support a new
file system type?  I would advise to use a system where users can use
their own implementation of file systems, without the help of the system
administrator.  But that may just be my Hurd-mind, and not something you
wish to care about. ;-)


This is possible. Currently, FS0 only provides an abstract interface to
access a real, low-level filesystem underneath. There is no mount
support yet, and this is because I haven't decided on how to do it the
best way. My expectation is that there is going to be standalone file
servers that are attached to the namespace of each process. FS0 will
take care of the main handling of the namespace management. For example
a driver, a communication stack, or a standalone filesystem will be able
to run this way. However, I also want to keep the option of having the
real filesystems bundled to FS0 for performance reasons.

Generally my thoughts are centered around building a microkernel-based
OS for embedded systems using Plan 9 design principles. What's better
though, is that new and legacy services can co-exist in a flattened hierarchy that doesn't increase system complexity.


Bahadir Balban

reply via email to

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