Introducing Helios
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Subtitle |
| |
| Title of Series | ||
| Number of Parts | 542 | |
| Author | ||
| License | CC Attribution 2.0 Belgium: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/61536 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
00:00
Kernel (computing)Source codeHacker (term)BootingLine (geometry)Portable communications deviceCodeArchitectureCompilerSystem programmingOperations researchSoftwareTask (computing)Programming languageMemory managementFluid staticsRun time (program lifecycle phase)CompilerOvalWeb pageInformation securityInterprozesskommunikationRead-only memorySimilarity (geometry)Scheduling (computing)Core dumpComputer hardwareMultiplicationCodeRing (mathematics)Kernel (computing)Term (mathematics)Software bugMultiplication signWritingPortable communications deviceLine (geometry)InterprozesskommunikationCompilerRight angleFloppy diskScheduling (computing)SpacetimeProblemorientierte ProgrammierspracheCASE <Informatik>Process (computing)Semiconductor memoryGoodness of fitHacker (term)Task (computing)AdditionMikrokernelDevice driverSystem programmingComputer hardwareRevision controlLatent heatArmComputer architectureProgramming languagePoint (geometry)Line codeMaxima and minimaSampling (statistics)Address spaceNamespaceBitOrder (biology)Web pageSynchronizationSystem callSubsetProjective planeBootingComputer animation
06:44
Slide ruleKernel (computing)BefehlsprozessorSerial portSpacetimeNetwork topologySystem on a chipBootingComputer configurationSoftware frameworkInterface (computing)System programmingOperations researchComplete metric spaceOnline chatLattice (order)Device driverProgramming languageSerial portKernel (computing)WebsiteComputer programmingData managementWeb pageProjective planeComputer hardwareEntire functionArmHacker (term)Link (knot theory)Slide ruleService (economics)BootingPlanningSoftware developerSoftware frameworkSpacetimeRing (mathematics)Core dumpAbstractionAdditionTerm (mathematics)Complete metric spaceMikrokernelArithmetic meanBuildingOperating systemConfiguration spaceSoftwareRevision controlSource codeNetwork topologyInterface (computing)Volume (thermodynamics)Computer animation
13:22
Lattice (order)Kernel (computing)Online chatComputer animationProgram flowchart
Transcript: English(auto-generated)
00:05
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?
00:22
These are the reasons that I came up with for writing new kernels. 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 Hair is useful for writing kernels. Hair is a programming language I developed along with many of the people in this room
00:43
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. Other goals is I want to know if we can do better than the SEL4 microkernel, which is a microkernel that inspired a lot of the system design for Helios, and if I
01:04
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. SEL4 is cool, but maybe we can do better, and you know at the end of
01:22
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 SEL4 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 x86-64 and ARM64 and support for RISC-V is coming,
01:45
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
02:01
under the GNU public license, and I suppose here I should mention these small line codes 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 a systems 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
02:24
Hair is a systems 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 systems programming. So that includes compilers, daemons, system tools, and also things like kernels. Further about Hair, again it's a
02:48
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
03:05
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, binutils is required, and it runs again on these three targets. If you've never seen any Hair code
03:24
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. Namespaces are nice, you
03:42
know, but this is just a peek at what Hair looks like, and this particular code sample is the entry point for the Helios microkernel, so this is the first line of portable code. There's also some architecture-specific setup 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?
04:06
It's a microkernel, 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
04:23
capabilities. It uses capability-based security, which is essentially this means of controlling access to resources on the system, like memory, like hardware I O, memory mapped I O, processes, threads, address spaces. All of these things are represented by capabilities, and the syscall API is used
04:42
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's design is more secure than
05:03
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 0, 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
05:25
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
05:41
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.
06:02
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
06:24
possible to write user space drivers for hardware in Helios or on top of Helios. And in terms of booting, we currently have support for EFI on ARM and multi-boot on x86-64. We're going to also bring EFI to x86-64 as soon as somebody can be bothered to implement position-independent code for
06:41
our backend. And does it work? The answer is self-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
07:02
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
07:21
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
07:41
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 okay images, on a tarball, which essentially acts like an initramfs, and there's basically no hacks here. This is not, you know, there's no smoke and mirrors. I actually
08:03
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 in the way of hacks.
08:21
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,
08:41
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, if you do a git grep on todo, you find about 100 things that still need to be fixed, just little stuff. We need to add multiprocessing support. I want to port it to RISC-V as well, which maybe it'll take more than 40 days, because I'm not going to,
09:04
you know, kill myself over this one without a deadline like FOSTA. I mentioned earlier that I want to expand the bootloader options, so I want to add EFI support for X86-64, and we also intend to boot RISC-V over EFI. And I want to improve the documentation, of course. The docs are actually already kind of okay.
09:22
They're at aeres-os.org, if you're curious. The kernel docs are maybe about 60 percent 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.
09:41
In the big picture, this is our plans. So like I said, the kernel is almost functionally complete, but it's a microkernel, 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 microkernel Helios,
10:03
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
10:25
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,
10:42
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 Ares, which will be a more complete operating system
11:01
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 Sivadi and Alexi Yerin, in particular,
11:22
for their early experiments with kernel programming in HAIR. These early kernels for x86 and RISC-V, 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 0? 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.
11:47
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.
12:03
I also want to thank the OS dev community on the Barotchats 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 0 yourself, this is an indispensable resource. Definitely check these guys out. And also, we owe some acknowledgments to SEL4,
12:24
because a lot of our design is inspired or stolen from SEL4. I should have updated this slide. We have birds of a feather and a couple of hours for HAIR, the programming language.
12:41
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,
13:04
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.