Hi, everyone. I'm Razvan. We are now a part of the microchannel component-based OS Devroom.
It's a pleasure to have you all here. We're going to start right away, so we have, I think,
10 talks. We're going to delve into microchannel, unical, and component-based OS topics. We're
going to start with Martin with his talk on the state of the microchannel environment. So,
Martin, please go ahead. Thank you. Good morning. Thanks for coming. Welcome. It's my pleasure and
honor to open this Devroom today. And it's also a great pleasure that we can continue this tradition
of this Devroom since 2012. I would like to thank Razvan for organizing the Devroom this year, and
let's go to it. So, my talk will be about the currently developed microchannels that I'm aware
of. Maybe I'm missing some, but this should be like an overview. If you might be interested in
seriously using a microchannel or just trying it out, what you can expect. This first slide is about
me. I won't go into it. Let me just say that I have been working with microchannels and contributing
to microchannels for almost 20 years now, half of my lifetime. I assume that most people here do
know what a microchannel is, or at least most people have some kind of idea. But I will still
try to very briefly introduce the microchannels to you. Maybe I will save a few minutes for the
follow-up speakers. So, a microchannel-based operating system is a fundamental way how to achieve
operating system reliability and dependability by the means of having purpose of the architecture,
especially driven by specific design principles. Now, every microchannel has their own design
principles. This is where the different implementations differ, obviously, but I think there are
like three common universal design principles, the separation of concerns, the split of mechanism
and policy, and the principle of least privilege. So, this generally results in a system that is
modular, customizable, and verifiable, potentially formally verifiable. By the way, some microchannels
do have a minimality as explicit design principle, but many microchannels actually don't. So,
the micro part in the microchannel and the whole microchannel term is a little bit of a
misnomer, at least as I see it, because I think the microchannel as small as possible is not
necessary. The a priori goal is just the result of the other design principles, and I really
think that there is no point in comparing whether one microchannel might have 20,000 lines of
code and they are 130,000. It's really comparing apples to oranges. These design principles also
don't affect just the kernel design, but potentially also the user space design. So,
therefore, you might see descriptions like microchannel multiserver operating system with
fine-grained components. This means that not only the kernel is non-monolithic, maybe that
would be a better term, but we are stuck with the microchannel term, but also this might suggest
that in many of these systems also there are no monoliths in the user space. I have some
slides about the history, but I will skip them. You can go to the slides if you are interested.
Just one note. The idea of micro kernels has been around almost as long as the idea of operating
systems. So, if some people say that micro kernels are strange, are this strange over-engineered
idea that proper operating systems should be monolithic because this was the way how
they started and etc., I don't think those are very valid arguments. So, let's go to
the core of my talk. There is a website, microkernel.info, which is basically a condensed
version of this. So, this is a very simple site that lists the current state-of-the-art
open source micro kernels. So, if you are interested or if you are looking around going
to this site, it's probably a good idea. By the way, this site was started by Jakub Mirmas,
my colleague, and I'm maintaining it right now. Of course, if you are a microkernel developer
and you don't see your project on this site, just send us a pull request. It's so simple.
Okay, let's start with the overview. I should say that there is surprisingly, there are
surprisingly many projects, active projects that are microkernel-based, and for microkernel
developer this is really exciting times, I would say. So, genode by genolabs is perhaps
the most versatile example of a microkernel-based operating system, but I mind you. It's actually
not an operating system in the common sense, like what you would consider Windows or a
GNU Linux distribution. It's actually an operating system construction kit. So, it's a way how
to pick and match different operating system components, including different micro kernels
or kernels in general, with some user space components and how to build a bespoke operating
system for your specific needs. So, what is really interesting about genode that you can
really use all these different microkernels like SCL4, Fiasco OC, microhypervisors like
NOVA, and you can even use their own custom microkernel, which is called base HW. You
can even run this infrastructure on top of Linux for development purposes, maybe. There
is strong focus on resource accounting and management in genode. You can read the genode
book for the details. Genode is driven by a commercial company. So, they have customers.
Somebody is paying them to do that. They don't state their references publicly, as far as
I know. I might note some, but I'm not in the liberty to name them. And there is also
this thing called SCALP OS, which is like a pre-built distribution of genode. So, if
you would like to try something that is, that you don't have to pre-configure in advance
for your specific needs, you can go for that. This is a picture from Norman Feske, one of
the co-authors of genode from, I think, FOSDOM 2017. So, maybe the image is a little bit
outdated, but I still think it gives you the big picture. So, you have all these components
like the different kernels, different user space, runtime environments, if I can say,
so this one is, for example, Unix-like runtime environment, drivers and UI components and
stuff like that, and you mix and match them. And then, this is a screenshot of the SCALP
OS, so, like, this one instantiation of genode, and you see that it's actually a nice desktop-oriented
operating system. As some final closing remarks to genode, I really like base HW, as I spoke,
microkernel for genode, because it's really nicely integrated with the rest of the system.
For some reason that I don't know, I don't understand, but there are genode guys here,
you can ask them. I don't see complete feature parity of base HW with the other microkernels
they support, so, as far as I know, there is no support for hardware virtualization.
And this is not a criticism, this is just a comment. If you start playing with genode,
you need to read some documentation. There is very nice documentation available, no
doubt about it, but, really, it's not so simple by just downloading an image and running it
and expecting a fully blown desktop environment, at least not from, you know, just by booting
it, you have to do something. But I think it's definitely worth it, so there are some
links you can follow. It's an open source project, by the way.
Okay, now, let me talk about L4E, which is something slightly similar in some aspects
different by my current employer, current concept. So, this is also a production grade
microkernel-based environment, a little bit more integrated, I would say, because we basically
support just the one kernel, which we called L4E microkernel, but you all know it by the
name Fiasco. We use this name currently because Fiasco is a very poor name, trust me. So,
we strongly focus on virtualization, we strongly focus on safety and security certification
currently, and we also have customers, because we are a company that pays us and et cetera.
I'm, again, not in the liberty to name them, but I can say that if you're going to buy
a new car from a German car manufacturer, there is a high chance you will be running
L4E. There will be L4E code running in the software stack of that car.
To be honest, the code base is not the most verbosely commented that I have seen, especially
the kernel itself. So, again, the learning curve is a little bit steep, but at least
there are some scenarios you can just build or download and pre-build image, and this
will show you the potential to a certain degree. And here are some links. Again, it's an open
source project. Now, let's talk about Helen OS, which is to compare with the previous
two is a slightly different breed. So, this is like an integrated operating system. So,
the purpose is to build it or download an image, boot it, and be presented with a desktop
environment with a shell and some mostly familiar commands, which you can use to explore the
system. So, it's not about compile time or deployment time configuration. It's really
about configuring the system at runtime as you go. What do you expect from a desktop-oriented
OS? And, of course, I'm a little bit biased because this is my project, but I would argue
that if you want to understand how a microkernel-based system works inside, this is the one to pick
because of the OS entry barrier. The code base is portable, self-contained, well-structured,
so, for example, we know how to use directories and not only a single level of them. So, this
is how we structure the system to be more understandable. The code is well-commented
and this is not just my observation. If you run a tool that will analyze the sources,
you will get a number around 30-35% of commands, which is not bad. And believe me, I have seen
many microkernel code bases. I have seen the code of many operating systems in general
and I can tell the difference. So, I would compare LNOS to something like the Solaris
kernel in terms of the structure and commands and stuff like that. And we also prefer to
use our native components, so, no ported components or components that might use some
unique kernel layers to really make the system feel coherent. Let's put it that way. So,
this is how it looks like when you boot the image which you can compile or download. So,
you have a user interface, a shell, et cetera. And we have some interesting features that
are not presented in the other microkernels. So, we are portable not only in theory but
also in real life. So, we support eight different architectures, including strange bits like
itanium. And yes, the RISC-5 port is still not finished and that goes to me. We are using
asynchronous IPC which transparently uses shared memory for performance. We have interrupt
controller drivers in user space compared to some other microkernels. We have a fully
decomponentized TCP IP stack. We support USB 3.0 and we have a sound stack, so, just
a few highlights. I will go quickly through these slides. We don't have the time to go
to the details but the microkernel, while being quite small, still has a structure. So,
we have a well-defined hardware abstraction layer in the kernel. This is how the user
space or how the entire architecture of the system looks like. So, you might see some
similarities with the genode image but the difference is that all of this is potentially
running in the system for all the time, I mean, depending on the actual configuration
of your machine. And there are some device drivers which are, again, somehow structured
in a tree, starting with some platform drivers, et cetera. If you want the details, please
come to me. Yeah, it's a community-driven effort currently. So, yeah, we are not so
fast regarding the development but we still do semi-regular releases and, sadly, we don't
support some of the new hardware features. If you'd like to contribute, you are more
than welcome. Fuchsia by Google is a relatively new kit on the block. It's a microkernel-based
system that is strongly focusing on Internet of Things. Specifically, their target is to
support maintenance, remote management, and remote upgrading of a fleet of devices. So,
imagine, for example, the Google Nest Hub, which is the device where Fuchsia is being
shipped currently with, and they even managed to do a remote update of all those, you know,
Nest Hubs from the previous Linux-based OS to Fuchsia over the air without the users
even noticing. So, I think this is quite impressive. The microkernel is called Zircon and it's
capability-based message-passing microkernel. And I have spoken to the developers why they
don't actually stress that it's microkernel. And it's their deliberate choice to somehow
underplay, understate that it's a microkernel because of some bad press of the term. So,
they don't call it microkernel explicitly unless you ask them, but it is a microkernel,
for sure. Yeah, this is how it looks like on the Nest Hub, or this is the way how you
can tell whether your device is still running Linux or is running Fuchsia. And, yeah, the
learning curve, again, somewhat steep because this is not a desktop-oriented system or server-oriented
system that would be Unix-like. You have to install a non-trivial toolchain and a custom
emulator sort of like when you do Android development and other things. But, again,
what would I believe is very nice about Fuchsia that they are only using their own native
core components, not ported components. And it's an open-source project.
Panagarm, again, a relatively younger operating system, which is microkernel-based, at least
compared to the first three. One of the key features, a fully asynchronous kernel design,
which tries to somehow mitigate some performance problems by implementing some features in the
kernel, which might not be considered pure by microkernel purists like the PageCache.
And Managarm tries to be compatible with Linux, so they already support the Wayline
protocol in Western and some other applications. They even have some accelerated GPU drivers,
so at least one. And it's an open-source project, and this is how it looks like. Of course,
you can run more than just a clock there, but, yeah, you get the idea.
Redux, another interesting microkernel-based operating system that tries to be Unix-like,
but this one has this primary feature of being implemented almost completely in Rust. Also,
the core user-based components are written in Rust, like the Lib-C, so they have actually
a C library written in Rust. Interesting. What to say, again, POSIX compatibility layer,
they already support some interesting end-user applications and libraries, and it's an open-source
project, again. And this is how it looks like when you boot it. So, again, you can run a
terminal with a bash in this case and just explore the system.
A little bit aside, there are also other, let's say, currently non-open-source microkernels
being around. I just tried to mention them here very quickly. I know we are at FOS them,
but just to complete the picture. So, Huawei is working on something which they call Humong.
It's actually quite buried under this HarmonyOS brand, and it's a little bit confusing because
you might have heard rumors, the original ones were that HarmonyOS will be a microkernel-based
system, then Huawei released something that was clearly Linux-based. So, yeah, this did
not resonate well with our technical folks, but the point is that this is just a marketing
confusion. So, the HarmonyOS is a common brand for different operating systems. One of them
is Linux-based, one of them is LiteOS-based, which is a real-time kernel by Huawei, and
the most progressive one unreleased so far is the microkernel-based. The microkernel
was originally inspired by best practices and state-of-the-art in other microkernels,
but it's a clean slate implementation and design. For example, they have capability-based
physical memory management in user space, so the kernel does not manage the physical
memory. It's sort of similar, the design is sort of similar to SCL4, but it's slightly
more practical in my personal opinion. Sorry that I can't go into the details, and they
also target safety and security certification, and actually this is also running in the wild
as trusted execution environment in several Huawei smartphones. Then there is this R&D
project called DAQ, which is primarily being driven by my former colleagues at the Dresden
Research Center, which tries to be, again, a completely clean slate design and implementation.
The primary goal was really to use state-of-the-art best practices and software engineering to
achieve really the highest code quality and maintainability. For example, one of the goals
was to be fully MISRACI compliant. Another goals were high-level safety and security
certification and other interesting features. It's an R&D project, and honestly, I don't
know what's the current state, maybe you can informally ask some of the Huawei guys here,
but it's good to know that this is there. Okay, very quickly, some other systems.
GNU Horde, for 30 years, the intended replacement of Linux in the GNU Linux equation, still
alive, still kicking, still with semi-regular releases, and yeah, I mean, you can actually
run 70% of the BN packages on top of it, which is not bad, I mean, honestly. Yes, it's limited
to 32-bit x86, but as I always say, if they would get 1, 3, 1, 1, 4 of the Linux contributors,
they would finish it in a few months. ARS, which is a microkernel-based operating system
based on the Helios microkernel, which is supposedly inspired by SCL4. There will be
a talk later today from the author, so I skip the details for now. Composite, another microkernel-based
project that is focusing on predictability and component composition. The kernel itself
is designed as lockless, and it has user space scheduling, and it uses thread migration IPC,
so if you remember vaguely the idea from Mach 3.0 from Ford at all, this is the continuation
of that. Then there is UXRT, which is like a user space part built on top of SCL4. This
is still an ongoing project in early stages of the development. Let's see how it goes.
And finally, let's mention a few standard microkernels, so these are not entire operating
systems, these are just the kernel building blocks. NOVA, microhypervisor by Udo, is again
alive and kicking. It has been used by bedrock systems as their primary product, as I believe.
So this is one of the projects that sort of went into limbo for many years, and now they
are alive again. By the way, G-Note, I believe, is maintaining their fork of NOVA, or maybe
NOVA with their own patches, but there is also Hadron, which is an official fork of NOVA
from Cybers, and they are also using it as their commercial product. Again, I think there
might be Julian somewhere here who might tell you more. SCL4, of course, the microkernel
with the most, I would say, the most visible formal verification story, we need to mention
it. We also need to say that Google has adopted SCL4 recently as their foundation for secure
firmware, sort of something like that. I'm not really sure what are the targets of this
can trip OS, also SCATA OS, but it's a static configuration mostly, so it's not a dynamic
system, it's a really static configuration system. And in that same area, I would mention
also the Muen separation kernel, which again is a separation kernel, so its primary goal
is to do static partitioning, but I think it belongs to the family. And sadly, there
are some microkernels that are interesting, worth looking into for inspiration, but are
currently in limbo, like Escape, M3, Minix 3, Herbigalia, and Redleaf. I hope they will
be resurrected. And of course, I might continue with a list of other microkernels that are
certifiably dead, and of course, those could be resurrected as well, and it's always good
to know the history, right? Yeah, but I would stop here. Thank you, and if there are any
questions, I would be happy to answer them. Right, thank you so much, Marty. If there are,
please. Thank you. We have time. Yeah, two questions, three questions. Hello, congratulations
for your excellent talk. Thank you. Among all those that you studied, which one do you
think would be more compatible to the Linux end user base, like for a person to use Minix
or... I mean, that is a good question. Thank you. So the question is, which of those systems
would be most Linux compatible? Most of them, actually, most of the systems that I've presented
do have some POSIX compatibility layers. So I would not make this as the only criterion.
I understand it might be important for you, but I would look also into other aspects of
that, because most of the systems do provide some kind of Linux compatibility. But if you
would be looking for something that is really Linux compatible by design, or that makes
it as one of its primary goals, then I would probably go for Managarm. But again, this
is just a first idea, first suggestion. I would not rule out the others.
Thank you. Any questions? Alex. Hi. Thank you for the talk. So what trends do you think
you'll see in the next few years with the microcodes? That's a tricky question, but thanks
for that. So the question was about the trends. So I think there will be this kind of retargeting
of the systems to very specific use cases like Fuchsia is doing, so really implementing
custom operating, microcode-based operating systems that really do fulfill the specific
needs of those areas. That's one thing. The other thing that I would like to see, I'm
not sure if it's going to happen soon, but I would like to see, I would like to see more
hardware software code design. So basically, the Achilles heel of microcodes is the fact
that most current CPUs don't really provide hardware features that would help the microcodes,
especially in the terms of performance. And we see this vicious cycle. The microcodes
are not performing greatly on the current hardware, so nobody is, nobody quote unquote
is using them. So the hardware vendors don't see a need for changing the CPUs to provide
features that would help the microcodes. But I think with RISC-5 and the possibility, or
the democratization of the hardware design, I think this might change hopefully quite
soon. And the third trend that I definitely see, which was probably also seen on the slides,
is really the certifications in terms of safety, security, and hopefully more formal verification,
because this is where microcodes really excel. So why not go for it?
Okay. Thank you so much, Martin. Thank you.