Hi everybody, my name is Drew DeVault and today I'm going to give a quick talk giving
you a sneak peek at a microkernel I've been working on called Helios.
So why should we write new kernels?
These are the reasons that I came up with for writing new kernels.
You know, is Linux good enough? I don't know, but kernel hacking is really, really fun.
So I'm enjoying myself working on it, which is reason enough.
I also want to prove if the programming language here is useful for writing kernels.
Here is a programming language I developed along with many of the people in this room
and many people outside of this room, which one of the stated goals is to be useful for
systems programming and to be able to write kernels with.
So in order to prove that that's possible, we have to write a kernel.
Another goal is I want to know if we can do better than the SCL4 microkernel, which is
a microkernel that inspired a lot of the system design for Helios.
And if I were to be particularly ambitious and bold, I would wonder if it's possible
to do better than Linux.
And so we've had Linux now for, what, 30 years, maybe a little bit less than 30 years.
And I think it's time for some innovation in kernels, SCL4 is cool, but maybe we can
do better.
And you know, at the end of the day, we're having fun doing it and that's enough.
So enter Helios.
Helios is a microkernel, which again is largely inspired by SCL4 and is written in hair to
prove that hair can be used to write kernels and also because it's fun to write kernels
and maybe we can make it good.
It runs right now on X8664 and ARM64 and support for risk 5 is coming, which is all of the
targets that hair presently supports.
The kernel itself is quite small.
The portable code base is about 8,500 lines of code.
And then on top of that, for each architecture, we have about 3,000 lines of code.
And that's it.
That's the whole microkernel.
The kernel is licensed under the GNU Public License and I suppose here, I should mention
these small line cuts don't include the bootloaders, which themselves maybe add 2,000 lines of
code per target.
And it's written in hair, which is again, assistance programming language that I designed
with the help of about 80 contributors.
This is the pitch from the website, but the short version is that hair is a assistance
programming language, which is designed to be very simple.
We have a specification, which is less than 100 pages.
We have a small compiler.
We have a minimal runtime, manual memory management.
And the goals is to use it for assistance programming.
So that includes compilers, daemons, system tools, and also things like kernels.
Further about hair, again, it's a general purpose systems programming language.
So in addition to kernels, we also use it in user space on Linux and FreeBSD, working
on OpenBSD and NetBSD user space support as well.
We've been working on it now for about three years.
And the footprint of the programming language is also small.
We have an 18,000 line compiler, our back end cube, not LLVM, our back end is cube,
which is about 12,000 lines of C99.
And together, this is enough to bootstrap the compiler plus, you know, benutils is required.
And it runs again on these three targets.
If you've never seen any hair code before, I just have a small sample here.
I'm not going to go into too much detail about exactly what any of this code does, but this
is just what it looks like.
If you're familiar with C, a lot of things here probably look fairly recognizable to
you.
Some things maybe don't.
Name spaces are nice, you know.
But this is just a peek at what hair looks like.
And this particular code sample is the entry point for the Helios macro kernel.
So this is the first line of portable code.
There's also some architecture specific set up code, and the bootloader runs before any
of this, but this is the first line of code that runs on all architectures.
So what is Helios?
What is the goal of the design?
It's a macro kernel, so it's designed to be as small as possible and to move any tasks
which can be performed in user space into user space, contrasted with something like
Linux, which is a monolithic design.
The kernel is very, very small and simple.
It only has 14 syscalls, of which 12 are related to capabilities.
It uses capability-based security, which is essentially this means of controlling access
to resources on the system, like memory, like hardware IO, memory mapped IO, processes,
threads, address spaces.
All of these things are represented by capabilities, and the syscall API is used for working with
those capabilities.
And then each process on the system has access to some subset of capabilities, which entitles
it to rights to use resources, which is a really good approach for sandboxing and security.
It's especially good when compared to a monolithic design like Linux.
The example I usually reach for to explain why Helios is designed is more secure than
Linux is to consider the case of a floppy disk driver.
So if you have a floppy disk driver on Linux, it's compiled into your kernel and runs in
ring zero, and if there's a bug in it, the worst thing that bug can do is completely
compromise your system.
Whereas on Helios, the worst thing a bug in your floppy disk driver could do is erase
your floppy disk.
All drivers, in addition to user space processes, are sandboxed with the MMU, just like user
space processes generally are on systems like Linux.
Of course, for a microkernel, inter-process communication is critical.
We have two approaches to IPC, which again are largely inspired by SEL4.
We have synchronous IPC via endpoints and asynchronous via notifications, as well as
the ability to set up shared memory so that you can communicate more efficiently than
using syscalls for IPC.
Where is the project at now?
It's fairly mature.
We're about nine months in.
The capabilities are working.
Inter-process communication is also working.
We also have preemptive scheduling, so we do actually have processes which get scheduled,
but the scheduler is very simple.
We don't have support for SMP yet, so it's all running on one core, and it's just a simple
round-robin scheduler, but we will make improvements in this domain.
We also have support for Hardware IO and IRQs, both in user space, so it is now possible
to write user space drivers for hardware in Helios or on top of Helios.
In terms of booting, we currently have support for EFI on ARM and multi-boot on X8664.
We're going to also bring EFI to X8664 as soon as somebody can be bothered to implement
a position-independent code for our backend.
And does it work?
The answer is self-edit, evidently, yes, because this slide deck you're viewing right now is
running on this Raspberry Pi, which is running on Helios.
I promised that I would not do any talks about Helios until I could actually present that
talk from Helios, and I initially was going to try and write an Intel HD graphics driver
from X86 laptop, and then I started looking at the IHD manuals, of which there's about
18 volumes per Intel hardware revision.
Among those are about 100,000 pages of PDF.
And after about two days of reading those PDFs, I forgot about that and instead ported
the entire kernel to ARM, so I could write a GPU driver for the Raspberry Pi instead.
That ARM port took about 42 days to complete from start to finish.
The Raspberry Pi here is running its GPU driver and a serial driver in user space.
The GPU driver is driving the projector, and I'm switching between slides by typing letters
into the serial port.
The slide deck itself is encoded as QOI, quite OK images, on a tarball, which essentially
acts like an in-it-RAMFS.
And there's basically no hacks here.
This is not, you know, there's no smoke in mirrors.
I actually ported the entire Helios kernel to ARM.
There's no SOC specific build, so this same configuration should work on any other ARM
device, which implements an EFI boot.
I am using EDK to boot through EFI.
I'm using device trees to enumerate the hardware instead of drivers, so there's very little
on the way of hacks.
42 days for a complete port to ARM, no hacks.
It just works.
Thank you.
So, where's the project going from here?
The kernel itself is done in big air quotes in terms of the fact that it's almost functionally
complete.
It needs to be polished, and we need to, you know, there's, if you do a git grab on to
do, you find about a hundred things that still need to be fixed, just little stuff.
We need to add multiprocessing support.
I want to port it to risk five as well, which maybe it'll take more than 40 days, because
I'm not going to, you know, kill myself over this one without a deadline like FOSSTEM.
I mentioned earlier that I want to expand the boot loader options, so I want to add
EFI support for X8664, and we also intend to boot risk five over EFI.
And I want to improve the documentation, of course.
The docs are actually already kind of okay.
They're at Aries A-E-R-S-O-S.org.
If you're curious, the kernel docs are maybe about 60% complete, and if you're curious
to play with Helios, you can definitely use those as a starting point, and ask an IRC
if you encounter a stub where there should be docs.
In the big picture, this is our plans.
So like I said, the kernel is almost functionally complete, but it's a macro kernel, so that
doesn't mean that it can necessarily do very much that it's useful.
But we're going to go to user space and build more stuff.
We have this idea of kind of layers of support.
So at the core is the micro kernel Helios, but then we're going to build additional projects
on top of it, which will expand it into a complete operating system.
We have now Mercury, which is a driver framework.
This already exists, and is fairly mature, and has become even more so in the past week
or so.
And then we've just started last week working on Venus, which is going to be our collection
of drivers, just any kind of hardware that we want to support.
The driver for it will probably end up in Venus and be built on top of the Mercury framework.
And together, these will present an interface to Gaia, which will take these abstractions
for accessing hardware and build them into an actual programming environment, which will
resemble Unix or Plan 9.
We're also going to build Luna, which will be a POSIX compatibility layer.
Gaia itself will not be POSIX.
I think that there's room for beyond POSIX, I hope.
But we do want POSIX software to work, so we'll have this compatibility layer.
And then we'll tie it all together with Aries, which will be a more complete operating system
that provides a package manager and a service manager and other things that you might be
used to from a complete experience.
I want to give some quick acknowledgments as well to the people who made this possible.
I want to thank Ember Saladi and Alexi Jiren, in particular, for their early experiments
with kernel programming and hair.
These early kernels for X86 and RISC-5, they never made it to user space.
They weren't very sophisticated, but they did answer a lot of the problems that needed
to be answered for us to know how do we do hair development in ring zero.
And so this was very valuable for establishing things like booting up, dealing with the MMU
and other questions for how to get a kernel going in hair.
And the hair community itself deserves a big shout out because none of this would be possible
without the immense amount of work which people have put into it.
Many of the people who contributed to hair are in this room, and I offer them my thanks.
But many people are not here.
There's about 80 people who went into making hair possible.
I also want to thank the OSDEV community on Liberichat's IRC.
These guys are incredibly smart and incredibly friendly and incredibly helpful.
And if you want to get involved in kernel hacking and do any kind of work in ring zero
yourself, this is an indispensable resource.
Definitely check these guys out.
And also we owe some acknowledgments to SEL4 because a lot of our design is inspired or
stolen from SEL4.
I should have updated this slide.
We have a burst of a feather and a couple of hours for hair, the programming language.
So it's not about Helios.
It's about the language that Helios is implemented in.
So if you want to learn more about the language, please come there.
There's also a talk tomorrow in the microkernel room where I'm going to have a full hour to
talk about Helios.
And I'll go into a lot more depth.
So you're welcome to come check that out.
If you want to see any resources online about the system, the links are here.
This is a link to the website, which contains mostly documentation, a link to the source
code, to the website for the programming language, and to the IRC channel where we hang out and
we'll answer your questions.
And that's it.
That's Helios.
Thank you very much.