[00:00.000 --> 00:10.960]  Hi everybody, my name is Drew DeVault and today I'm going to give a quick talk giving
[00:10.960 --> 00:18.040]  you a sneak peek at a microkernel I've been working on called Helios.
[00:18.040 --> 00:22.320]  So why should we write new kernels?
[00:22.320 --> 00:25.840]  These are the reasons that I came up with for writing new kernels.
[00:25.840 --> 00:30.360]  You know, is Linux good enough? I don't know, but kernel hacking is really, really fun.
[00:30.360 --> 00:34.280]  So I'm enjoying myself working on it, which is reason enough.
[00:34.280 --> 00:39.720]  I also want to prove if the programming language here is useful for writing kernels.
[00:39.720 --> 00:43.040]  Here is a programming language I developed along with many of the people in this room
[00:43.040 --> 00:48.400]  and many people outside of this room, which one of the stated goals is to be useful for
[00:48.400 --> 00:50.960]  systems programming and to be able to write kernels with.
[00:50.960 --> 00:55.040]  So in order to prove that that's possible, we have to write a kernel.
[00:55.040 --> 00:58.960]  Another goal is I want to know if we can do better than the SCL4 microkernel, which is
[00:58.960 --> 01:03.680]  a microkernel that inspired a lot of the system design for Helios.
[01:03.680 --> 01:08.600]  And if I were to be particularly ambitious and bold, I would wonder if it's possible
[01:08.600 --> 01:10.680]  to do better than Linux.
[01:10.680 --> 01:16.160]  And so we've had Linux now for, what, 30 years, maybe a little bit less than 30 years.
[01:16.160 --> 01:20.200]  And I think it's time for some innovation in kernels, SCL4 is cool, but maybe we can
[01:20.200 --> 01:21.200]  do better.
[01:21.200 --> 01:25.960]  And you know, at the end of the day, we're having fun doing it and that's enough.
[01:25.960 --> 01:27.360]  So enter Helios.
[01:27.360 --> 01:33.320]  Helios is a microkernel, which again is largely inspired by SCL4 and is written in hair to
[01:33.320 --> 01:37.360]  prove that hair can be used to write kernels and also because it's fun to write kernels
[01:37.360 --> 01:39.320]  and maybe we can make it good.
[01:39.320 --> 01:45.680]  It runs right now on X8664 and ARM64 and support for risk 5 is coming, which is all of the
[01:45.680 --> 01:48.600]  targets that hair presently supports.
[01:48.600 --> 01:51.000]  The kernel itself is quite small.
[01:51.000 --> 01:54.480]  The portable code base is about 8,500 lines of code.
[01:54.480 --> 01:58.160]  And then on top of that, for each architecture, we have about 3,000 lines of code.
[01:58.160 --> 01:59.160]  And that's it.
[01:59.160 --> 02:00.480]  That's the whole microkernel.
[02:00.480 --> 02:05.480]  The kernel is licensed under the GNU Public License and I suppose here, I should mention
[02:05.480 --> 02:09.120]  these small line cuts don't include the bootloaders, which themselves maybe add 2,000 lines of
[02:09.120 --> 02:12.480]  code per target.
[02:12.480 --> 02:17.080]  And it's written in hair, which is again, assistance programming language that I designed
[02:17.080 --> 02:20.120]  with the help of about 80 contributors.
[02:20.120 --> 02:24.800]  This is the pitch from the website, but the short version is that hair is a assistance
[02:24.800 --> 02:27.800]  programming language, which is designed to be very simple.
[02:27.800 --> 02:30.680]  We have a specification, which is less than 100 pages.
[02:30.680 --> 02:31.880]  We have a small compiler.
[02:31.880 --> 02:35.040]  We have a minimal runtime, manual memory management.
[02:35.040 --> 02:37.800]  And the goals is to use it for assistance programming.
[02:37.800 --> 02:46.120]  So that includes compilers, daemons, system tools, and also things like kernels.
[02:46.120 --> 02:49.920]  Further about hair, again, it's a general purpose systems programming language.
[02:49.920 --> 02:54.840]  So in addition to kernels, we also use it in user space on Linux and FreeBSD, working
[02:54.840 --> 02:58.480]  on OpenBSD and NetBSD user space support as well.
[02:58.480 --> 03:01.600]  We've been working on it now for about three years.
[03:01.600 --> 03:06.080]  And the footprint of the programming language is also small.
[03:06.080 --> 03:11.080]  We have an 18,000 line compiler, our back end cube, not LLVM, our back end is cube,
[03:11.080 --> 03:13.760]  which is about 12,000 lines of C99.
[03:13.760 --> 03:19.320]  And together, this is enough to bootstrap the compiler plus, you know, benutils is required.
[03:19.320 --> 03:22.920]  And it runs again on these three targets.
[03:22.920 --> 03:26.280]  If you've never seen any hair code before, I just have a small sample here.
[03:26.280 --> 03:31.680]  I'm not going to go into too much detail about exactly what any of this code does, but this
[03:31.680 --> 03:33.800]  is just what it looks like.
[03:33.800 --> 03:38.080]  If you're familiar with C, a lot of things here probably look fairly recognizable to
[03:38.080 --> 03:39.080]  you.
[03:39.080 --> 03:40.400]  Some things maybe don't.
[03:40.400 --> 03:42.920]  Name spaces are nice, you know.
[03:42.920 --> 03:44.840]  But this is just a peek at what hair looks like.
[03:44.840 --> 03:48.560]  And this particular code sample is the entry point for the Helios macro kernel.
[03:48.560 --> 03:50.920]  So this is the first line of portable code.
[03:50.920 --> 03:54.760]  There's also some architecture specific set up code, and the bootloader runs before any
[03:54.760 --> 04:01.160]  of this, but this is the first line of code that runs on all architectures.
[04:01.160 --> 04:03.600]  So what is Helios?
[04:03.600 --> 04:06.200]  What is the goal of the design?
[04:06.200 --> 04:10.640]  It's a macro kernel, so it's designed to be as small as possible and to move any tasks
[04:10.640 --> 04:14.600]  which can be performed in user space into user space, contrasted with something like
[04:14.600 --> 04:17.480]  Linux, which is a monolithic design.
[04:17.480 --> 04:19.840]  The kernel is very, very small and simple.
[04:19.840 --> 04:23.400]  It only has 14 syscalls, of which 12 are related to capabilities.
[04:23.400 --> 04:29.280]  It uses capability-based security, which is essentially this means of controlling access
[04:29.280 --> 04:35.880]  to resources on the system, like memory, like hardware IO, memory mapped IO, processes,
[04:35.880 --> 04:37.720]  threads, address spaces.
[04:37.720 --> 04:42.320]  All of these things are represented by capabilities, and the syscall API is used for working with
[04:42.320 --> 04:43.680]  those capabilities.
[04:43.680 --> 04:48.240]  And then each process on the system has access to some subset of capabilities, which entitles
[04:48.240 --> 04:54.520]  it to rights to use resources, which is a really good approach for sandboxing and security.
[04:54.520 --> 04:58.280]  It's especially good when compared to a monolithic design like Linux.
[04:58.280 --> 05:03.240]  The example I usually reach for to explain why Helios is designed is more secure than
[05:03.240 --> 05:06.880]  Linux is to consider the case of a floppy disk driver.
[05:06.880 --> 05:12.200]  So if you have a floppy disk driver on Linux, it's compiled into your kernel and runs in
[05:12.200 --> 05:16.120]  ring zero, and if there's a bug in it, the worst thing that bug can do is completely
[05:16.120 --> 05:17.480]  compromise your system.
[05:17.480 --> 05:21.920]  Whereas on Helios, the worst thing a bug in your floppy disk driver could do is erase
[05:21.920 --> 05:24.040]  your floppy disk.
[05:24.040 --> 05:29.040]  All drivers, in addition to user space processes, are sandboxed with the MMU, just like user
[05:29.040 --> 05:32.640]  space processes generally are on systems like Linux.
[05:32.640 --> 05:36.240]  Of course, for a microkernel, inter-process communication is critical.
[05:36.240 --> 05:40.720]  We have two approaches to IPC, which again are largely inspired by SEL4.
[05:40.720 --> 05:45.360]  We have synchronous IPC via endpoints and asynchronous via notifications, as well as
[05:45.360 --> 05:50.400]  the ability to set up shared memory so that you can communicate more efficiently than
[05:50.400 --> 05:54.840]  using syscalls for IPC.
[05:54.840 --> 05:57.120]  Where is the project at now?
[05:57.120 --> 05:58.560]  It's fairly mature.
[05:58.560 --> 06:00.320]  We're about nine months in.
[06:00.320 --> 06:02.640]  The capabilities are working.
[06:02.640 --> 06:04.680]  Inter-process communication is also working.
[06:04.680 --> 06:09.080]  We also have preemptive scheduling, so we do actually have processes which get scheduled,
[06:09.080 --> 06:10.400]  but the scheduler is very simple.
[06:10.400 --> 06:15.680]  We don't have support for SMP yet, so it's all running on one core, and it's just a simple
[06:15.680 --> 06:19.200]  round-robin scheduler, but we will make improvements in this domain.
[06:19.200 --> 06:24.120]  We also have support for Hardware IO and IRQs, both in user space, so it is now possible
[06:24.120 --> 06:29.360]  to write user space drivers for hardware in Helios or on top of Helios.
[06:29.360 --> 06:35.360]  In terms of booting, we currently have support for EFI on ARM and multi-boot on X8664.
[06:35.360 --> 06:39.680]  We're going to also bring EFI to X8664 as soon as somebody can be bothered to implement
[06:39.680 --> 06:44.280]  a position-independent code for our backend.
[06:44.280 --> 06:45.280]  And does it work?
[06:45.280 --> 06:49.640]  The answer is self-edit, evidently, yes, because this slide deck you're viewing right now is
[06:49.640 --> 06:53.440]  running on this Raspberry Pi, which is running on Helios.
[06:53.440 --> 06:59.160]  I promised that I would not do any talks about Helios until I could actually present that
[06:59.160 --> 07:05.920]  talk from Helios, and I initially was going to try and write an Intel HD graphics driver
[07:05.920 --> 07:11.480]  from X86 laptop, and then I started looking at the IHD manuals, of which there's about
[07:11.480 --> 07:14.720]  18 volumes per Intel hardware revision.
[07:14.720 --> 07:19.320]  Among those are about 100,000 pages of PDF.
[07:19.320 --> 07:24.520]  And after about two days of reading those PDFs, I forgot about that and instead ported
[07:24.520 --> 07:30.960]  the entire kernel to ARM, so I could write a GPU driver for the Raspberry Pi instead.
[07:30.960 --> 07:36.240]  That ARM port took about 42 days to complete from start to finish.
[07:36.240 --> 07:41.720]  The Raspberry Pi here is running its GPU driver and a serial driver in user space.
[07:41.720 --> 07:46.880]  The GPU driver is driving the projector, and I'm switching between slides by typing letters
[07:46.880 --> 07:49.160]  into the serial port.
[07:49.160 --> 07:55.640]  The slide deck itself is encoded as QOI, quite OK images, on a tarball, which essentially
[07:55.640 --> 07:57.760]  acts like an in-it-RAMFS.
[07:57.760 --> 07:59.480]  And there's basically no hacks here.
[07:59.480 --> 08:02.320]  This is not, you know, there's no smoke in mirrors.
[08:02.320 --> 08:06.440]  I actually ported the entire Helios kernel to ARM.
[08:06.440 --> 08:10.640]  There's no SOC specific build, so this same configuration should work on any other ARM
[08:10.640 --> 08:13.000]  device, which implements an EFI boot.
[08:13.000 --> 08:15.600]  I am using EDK to boot through EFI.
[08:15.600 --> 08:20.120]  I'm using device trees to enumerate the hardware instead of drivers, so there's very little
[08:20.120 --> 08:21.120]  on the way of hacks.
[08:21.120 --> 08:25.640]  42 days for a complete port to ARM, no hacks.
[08:25.640 --> 08:26.640]  It just works.
[08:26.640 --> 08:30.160]  Thank you.
[08:30.160 --> 08:39.360]  So, where's the project going from here?
[08:39.360 --> 08:45.360]  The kernel itself is done in big air quotes in terms of the fact that it's almost functionally
[08:45.360 --> 08:46.360]  complete.
[08:46.360 --> 08:50.920]  It needs to be polished, and we need to, you know, there's, if you do a git grab on to
[08:50.920 --> 08:55.560]  do, you find about a hundred things that still need to be fixed, just little stuff.
[08:55.560 --> 08:57.560]  We need to add multiprocessing support.
[08:57.560 --> 09:02.720]  I want to port it to risk five as well, which maybe it'll take more than 40 days, because
[09:02.720 --> 09:07.880]  I'm not going to, you know, kill myself over this one without a deadline like FOSSTEM.
[09:07.880 --> 09:10.960]  I mentioned earlier that I want to expand the boot loader options, so I want to add
[09:10.960 --> 09:17.520]  EFI support for X8664, and we also intend to boot risk five over EFI.
[09:17.520 --> 09:20.240]  And I want to improve the documentation, of course.
[09:20.240 --> 09:22.360]  The docs are actually already kind of okay.
[09:22.360 --> 09:25.600]  They're at Aries A-E-R-S-O-S.org.
[09:25.600 --> 09:30.840]  If you're curious, the kernel docs are maybe about 60% complete, and if you're curious
[09:30.840 --> 09:35.680]  to play with Helios, you can definitely use those as a starting point, and ask an IRC
[09:35.680 --> 09:41.400]  if you encounter a stub where there should be docs.
[09:41.400 --> 09:44.120]  In the big picture, this is our plans.
[09:44.120 --> 09:47.800]  So like I said, the kernel is almost functionally complete, but it's a macro kernel, so that
[09:47.800 --> 09:51.120]  doesn't mean that it can necessarily do very much that it's useful.
[09:51.120 --> 09:55.560]  But we're going to go to user space and build more stuff.
[09:55.560 --> 10:00.200]  We have this idea of kind of layers of support.
[10:00.200 --> 10:04.680]  So at the core is the micro kernel Helios, but then we're going to build additional projects
[10:04.680 --> 10:09.200]  on top of it, which will expand it into a complete operating system.
[10:09.200 --> 10:11.720]  We have now Mercury, which is a driver framework.
[10:11.720 --> 10:16.240]  This already exists, and is fairly mature, and has become even more so in the past week
[10:16.240 --> 10:17.560]  or so.
[10:17.560 --> 10:21.880]  And then we've just started last week working on Venus, which is going to be our collection
[10:21.880 --> 10:26.240]  of drivers, just any kind of hardware that we want to support.
[10:26.240 --> 10:30.440]  The driver for it will probably end up in Venus and be built on top of the Mercury framework.
[10:30.440 --> 10:36.360]  And together, these will present an interface to Gaia, which will take these abstractions
[10:36.360 --> 10:42.360]  for accessing hardware and build them into an actual programming environment, which will
[10:42.360 --> 10:44.840]  resemble Unix or Plan 9.
[10:44.840 --> 10:48.560]  We're also going to build Luna, which will be a POSIX compatibility layer.
[10:48.560 --> 10:50.160]  Gaia itself will not be POSIX.
[10:50.160 --> 10:54.600]  I think that there's room for beyond POSIX, I hope.
[10:54.600 --> 10:58.160]  But we do want POSIX software to work, so we'll have this compatibility layer.
[10:58.160 --> 11:01.320]  And then we'll tie it all together with Aries, which will be a more complete operating system
[11:01.320 --> 11:06.480]  that provides a package manager and a service manager and other things that you might be
[11:06.480 --> 11:11.440]  used to from a complete experience.
[11:11.440 --> 11:18.600]  I want to give some quick acknowledgments as well to the people who made this possible.
[11:18.600 --> 11:22.880]  I want to thank Ember Saladi and Alexi Jiren, in particular, for their early experiments
[11:22.880 --> 11:25.200]  with kernel programming and hair.
[11:25.200 --> 11:29.920]  These early kernels for X86 and RISC-5, they never made it to user space.
[11:29.920 --> 11:33.200]  They weren't very sophisticated, but they did answer a lot of the problems that needed
[11:33.200 --> 11:37.520]  to be answered for us to know how do we do hair development in ring zero.
[11:37.520 --> 11:42.760]  And so this was very valuable for establishing things like booting up, dealing with the MMU
[11:42.760 --> 11:46.680]  and other questions for how to get a kernel going in hair.
[11:46.680 --> 11:50.440]  And the hair community itself deserves a big shout out because none of this would be possible
[11:50.440 --> 11:53.920]  without the immense amount of work which people have put into it.
[11:53.920 --> 11:58.200]  Many of the people who contributed to hair are in this room, and I offer them my thanks.
[11:58.200 --> 11:59.400]  But many people are not here.
[11:59.400 --> 12:03.000]  There's about 80 people who went into making hair possible.
[12:03.000 --> 12:08.320]  I also want to thank the OSDEV community on Liberichat's IRC.
[12:08.320 --> 12:12.280]  These guys are incredibly smart and incredibly friendly and incredibly helpful.
[12:12.280 --> 12:15.880]  And if you want to get involved in kernel hacking and do any kind of work in ring zero
[12:15.880 --> 12:19.520]  yourself, this is an indispensable resource.
[12:19.520 --> 12:21.360]  Definitely check these guys out.
[12:21.360 --> 12:27.840]  And also we owe some acknowledgments to SEL4 because a lot of our design is inspired or
[12:27.840 --> 12:31.800]  stolen from SEL4.
[12:31.800 --> 12:35.640]  I should have updated this slide.
[12:35.640 --> 12:40.800]  We have a burst of a feather and a couple of hours for hair, the programming language.
[12:40.800 --> 12:42.000]  So it's not about Helios.
[12:42.000 --> 12:44.200]  It's about the language that Helios is implemented in.
[12:44.200 --> 12:46.840]  So if you want to learn more about the language, please come there.
[12:46.840 --> 12:51.320]  There's also a talk tomorrow in the microkernel room where I'm going to have a full hour to
[12:51.320 --> 12:52.320]  talk about Helios.
[12:52.320 --> 12:53.600]  And I'll go into a lot more depth.
[12:53.600 --> 12:55.960]  So you're welcome to come check that out.
[12:55.960 --> 12:59.800]  If you want to see any resources online about the system, the links are here.
[12:59.800 --> 13:04.760]  This is a link to the website, which contains mostly documentation, a link to the source
[13:04.760 --> 13:09.640]  code, to the website for the programming language, and to the IRC channel where we hang out and
[13:09.640 --> 13:12.000]  we'll answer your questions.
[13:12.000 --> 13:13.000]  And that's it.
[13:13.000 --> 13:14.000]  That's Helios.
[13:14.000 --> 13:31.840]  Thank you very much.