L4.sec status ping

[Ernst Rohlicek jun.]

> Hi,

Hi Marcus,


> L4.sec is (and probably will be for quite some time) an experiment that
> is still worked on in our group. Mainly due to maintenance and support
> issues the sources have not been officially released yet. Our roadmap
> regarding L4.sec is to continue experimenting with capabilities and user
> controlled kernel memory management. Some of the results we already
> integrated into the Fiasco kernel, which is our mainstream kernel as for
> now. These include kernel memory quotas, security monitor style IPC
> permissions (though no local names yet). Others are likely to be
> integrated in some form in the Nova microhypervisor, which we are
> currently developing in the course of the Robin project.

User-controlled memory management sounds interesting -


>> Reason is: I need to choose a microkernel to start working on an
>> experimental operating system within this year I need some facts for
>> decision-making - and I would prefer a capability-based one like L4.sec.
>>   
> Can you elaborate a little on what you plan to do? Possibly, we can give
> you more advice on which kernel to use once we know what your plans are.

Sure.

I'm glad you asked - there are quite a few new microkernels out there,
and even the various L4 variants are still a bit obscure to me.

Generally, the goal of the experiment is to take a micro-kernel, which
interacts with the hardware and provides basic abstractions for it
(threads, memory, scheduling, interrupts, etc.) and get a high-level
runtime environment running as directly on top of it as possible.

This would be a pervasively OO, multi-language-capable, extremely
dynamic one (like combining .NET and the powers of Ruby/Smalltalk/Lisp),
which, yet, compiles to machine-code, so presumably is quite fast - and
is already in development.

The advantage would be that the system would be programmable from the
bottom up in a high-level (ie. not C/C++) programming language, which is
known to developers from other platforms, since any syntactic
conventions would be defineable, "We write an operating system in
JavaScript - or Python if you like to - or ..."

(If you're interested, see http://www.piumarta.com/papers/ .)

On the security side, according to my research, capability security is
close to "the insurmountable security paradigm" there is - in order to
protect the objects of each process properly from each other, especially
since much of the OS services would be inside the same runtime.

And I'd like to start this year sometime :-)


> Best regards
> 
>     Marcus

Thanks in advance,

Ernst Rohlicek jun.
<ernst.rohlicek at inode.at>