headers
Bahadir Balban | 11 Jun 13:46
Favicon

[ANNOUNCE] Introducing Codezero

Hi Everyone,

l4-hurd activity seems to have come to a halt.

I would like to announce my ongoing work on a new L4 microkernel called 
Codezero. Codezero is a modern L4 microkernel implementation written in 
C. It targets embedded platforms, supports the ARM architecture, and 
aims to implement both virtualization and native OS components in one 
system.

Codezero has a design and API that is similar to existing L4 
microkernels such as Pistachio.

The software currently comes with two services: First one is the default 
pager called MM0 that provides memory management capabilities with a 
POSIX-like API. It supports proper demand paging and implements calls 
such as fork, clone, execve, exit, mmap, shm.

The second service is called FS0 and it implements the virtual 
filesystem layer. This service supports calls such as open, close, read, 
write, lseek, stat, fsync, etc.

I believe the triplet is closest to what you (or at least I, given the 
past versions of Hurd) would imagine or expect to have as an OS core 
based around L4.

The software comes with a GPLv3 license, and a copyright share agreement 
option for contributions. The source code base is fairly clean and easy 
to play with. I encourage anybody interested in development to join.
(Continue reading)

Permalink | Reply | 35 comments |
headers
olafBuddenhagen | 15 Jun 03:53
Picon

Re: [ANNOUNCE] Introducing Codezero

Hi,

On Thu, Jun 11, 2009 at 02:46:50PM +0300, Bahadir Balban wrote:

> I would like to announce my ongoing work on a new L4 microkernel
> called  Codezero. Codezero is a modern L4 microkernel implementation
> written in  C. It targets embedded platforms, supports the ARM
> architecture, and  aims to implement both virtualization and native OS
> components in one  system.
>
> Codezero has a design and API that is similar to existing L4
> microkernels such as Pistachio.

Pistachio? Does that mean that just like Pistachio it has no kernel
support for protected IPC? If so, this is a total show-stopper -- it was
the main reason why the original Hurd/L4 port has been abandoned...

> The software currently comes with two services: First one is the
> default  pager called MM0 that provides memory management capabilities
> with a  POSIX-like API. It supports proper demand paging and
> implements calls  such as fork, clone, execve, exit, mmap, shm.
>
> The second service is called FS0 and it implements the virtual
> filesystem layer. This service supports calls such as open, close,
> read,  write, lseek, stat, fsync, etc.
>
> I believe the triplet is closest to what you (or at least I, given the
> past versions of Hurd) would imagine or expect to have as an OS core
> based around L4.
(Continue reading)

Permalink | Reply | 34 comments |
headers
Bahadir Balban | 21 Jun 21:31
Favicon

Re: [ANNOUNCE] Introducing Codezero

olafBuddenhagen <at> gmx.net wrote:
> Hi,
> 
> Pistachio? Does that mean that just like Pistachio it has no kernel
> support for protected IPC? If so, this is a total show-stopper -- it was
> the main reason why the original Hurd/L4 port has been abandoned...
> 

Hi there,

Yes I can understand that this is a limitation. IPC on Codezero is not
controlled, yet. It's version 0.1 after all. It is possible to implement
this, and one option is to add capabilities. But it won't be 
object-based capabilities because I generaly oppose designing everything 
around object oriented methods.

In my opinion, object-based design is useful on some occasions, but
software (and systems) are more ad-hoc in nature than being modeled
around a well-structured object system. The short conclusion is that if
you enforce objects everywhere, you end up over-designing your system.

So, I will certainly come up with a capability/security mechanism at
some point, but this won't be centered around an object-based design.

>> I believe the triplet is closest to what you (or at least I, given the
>> past versions of Hurd) would imagine or expect to have as an OS core
>> based around L4.
> 
> Not really: the Hurd does *not* have a central VFS layer.
>
(Continue reading)

Permalink | Reply | 33 comments |
headers
Bas Wijnen | 22 Jun 15:36
Picon
Favicon

Re: [ANNOUNCE] Introducing Codezero

Hi,

On Sun, Jun 21, 2009 at 10:31:21PM +0300, Bahadir Balban wrote:
> olafBuddenhagen <at> gmx.net wrote:
>> Pistachio? Does that mean that just like Pistachio it has no kernel
>> support for protected IPC? If so, this is a total show-stopper -- it was
>> the main reason why the original Hurd/L4 port has been abandoned...
>
> Yes I can understand that this is a limitation. IPC on Codezero is not
> controlled, yet. It's version 0.1 after all. It is possible to implement
> this, and one option is to add capabilities.

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.

Note that I'm not saying you should make a capability-kernel.  If you
like L4, it makes sense to write something like it.  I'm just saying
that "turning it into a capability kernel" may not be as trivial as you
make it sound.  So it may be better to simply not make that a goal. :-)

> But it won't be  object-based capabilities because I generaly oppose
> designing everything  around object oriented methods.

What I've seen from capability systems, they can be seen by object
(Continue reading)

Permalink | Reply | 31 comments |
headers
James Collier | 27 Jun 16:11
Picon

Viengoos IPC

Hello everyone,
This is my first post to any GNU mailing list. Finally I have some time
to play around with Viengoos. 
I've been trying to work out message passing / IPC.
I'm trying to achieve something like what Neal wrote as example code for
GNU Mach IPC [1] using viengoos' vg_ipc* interface.
What I'm trying to accomplish in the following code is an ipc send
operation from the main() thread and an ipc receive operation from the
hello_server thread. i.e. enqueue a messenger on hello_servers
messenger, then dequeue it from hello_server.
I've looked over some stuff in libhurd-mm/, hurd/ and libvingoos/ and
this is what I've come up with:

<code>
/* struct messenger appears in the kernel headers, how is it
initialised? */
vg_messenger_t client_msnger;
/* GLOBAL */ vg_messenger_t receive;
/* used by the server thread. Global so that vg_ipc* in this thread can
access it, does it need to? */

char* string = "hello";
/* Create the server thread */
pthread_t srvr;
pthread_create(&srvr, NULL, (void*) &hello_server, &client_msnger);

/* Allocate a message buffer
* -- Can hurd_message_buffer_alloc() help here?
* Is the following the correct/expected method?
*/
(Continue reading)

Permalink | Reply | 3 comments |
headers
olafBuddenhagen | 28 Jun 23:28
Picon

Re: [ANNOUNCE] Introducing Codezero

Hi,

On Sun, Jun 21, 2009 at 10:31:21PM +0300, Bahadir Balban wrote:
> olafBuddenhagen <at> gmx.net wrote:

> IPC on Codezero is not controlled, yet. It's version 0.1 after all. It
> is possible to implement this, and one option is to add capabilities.
> But it won't be  object-based capabilities because I generaly oppose
> designing everything  around object oriented methods.

I'm not very familiar with the terminology, and "object oriented" is an
extremely blurry term anyways. I have no idea what it means here...

> In my opinion, object-based design is useful on some occasions, but
> software (and systems) are more ad-hoc in nature than being modeled
> around a well-structured object system. The short conclusion is that
> if you enforce objects everywhere, you end up over-designing your
> system.

I totally agree on this, regarding OO programming languages...

I'm not sure how it applies to capability systems, though.

> OK I agree that the latest work on Hurd does not reflect what I meant.
> I roughly meant a microkernel-based OS core that has servers
> implemented in userspace.

That's what *every* true microkernel design is...

> Anyways, these are my general thoughts. I can go into more detail if
(Continue reading)

Permalink | Reply | 0 comments |
headers
Bahadir Balban | 1 Jul 09:10
Favicon

Re: [ANNOUNCE] Introducing Codezero

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
(Continue reading)

Permalink | Reply | 30 comments |
headers
Bas Wijnen | 1 Jul 16:13
Picon
Favicon

Re: [ANNOUNCE] Introducing Codezero

Hi,

On Wed, Jul 01, 2009 at 10:10:25AM +0300, Bahadir Balban 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.
>
> 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.

I don't have enough idea about the code to know how good that would
work.  Does your kernel use dynamic memory itself, by the way?  In other
words, can the kernel get out-of-memory errors?

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

Yes, that should not be much work.  I would expect no security-features
in the servers, because they simply cannot be contacted by untrusted
(Continue reading)

Permalink | Reply | 7 comments |

Gmane