Multi-Server Microkernel OS Genode 12.11 Can Build Itself

An anonymous reader wrote in with a story on OS News about the latest release of the Genode Microkernel OS Framework. Brought to you by the research labs at TU Dresden, Genode is based on the L4 microkernel and aims to provide a framework for writing multi-server operating systems (think the Hurd, but with even device drivers as userspace tasks). Until recently, the primary use of L4 seems to have been as a glorified Hypervisor for Linux, but now that's changing: the Genode example OS can build itself on itself: "Even though there is a large track record of individual programs and libraries ported to the environment, those programs used to be self-sustaining applications that require only little interaction with other programs. In contrast, the build system relies on many utilities working together using mechanisms such as files, pipes, output redirection, and execve. The Genode base system does not come with any of those mechanisms let alone the subtle semantics of the POSIX interface as expected by those utilities. Being true to microkernel principles, Genode's API has a far lower abstraction level and is much more rigid in scope." The detailed changelog has information on the huge architectural overhaul of this release. One thing this release features that Hurd still doesn't have: working sound support. For those unfamiliar with multi-server systems, the project has a brief conceptual overview document.

Comments

No plans for LLVM

[Bogtha]

For anybody wondering:

Switching from GCC to LLVM is not planned. From what I gathered so far, LLVM is pretty intriguing and I am tempted to explore it. But on the other hand, we are actually quite happy with our current GCC-based tool chain.

Re:No plans for LLVM

[Gerald]

Because GCC doesn't have a static analyzer (you do analyze your code, right?) LLVM's analyzer (Clang's scan-build) is very good. Visual C++'s analyzer was crap a few releases ago but even it is getting better. I like GCC but it has a lot of catching up to do in this regard. And no, "-Wall" isn't nearly the same.

Re:No plans for LLVM

[loufoque]

There are no mid-range 6-core systems.
Mid-range is dual core with hyperthreading.

Re:No plans for LLVM

[Anonymous Coward]

I'd rather concentrate on getting server code running natively no matter the toolchain used.

"We have a microkernel that can compile with LLVM" is not as cool as "run your apache pg and php/java/whatever in a microkernel built with security and accountability in mind".

Re:No plans for LLVM

[Entrope]

Microkernels are long on the "security and accountability" hype and somewhat short on reality. Sure, the services provided by the microkernel are less likely to have bugs or holes than a monolithic kernel -- but that's because the microkernel doesn't provide most of the monolithic kernel's functionality. Once you roll in all the device drivers, network stack, and the rest, the microkernel-based system is generally at least as bloated and typically less performant.

Re:No plans for LLVM

[serviscope_minor]

That's just not correct.

A Phenom II x6, especially the lower clocking ones are certainly not high end any more.

A dual core system is now certainly low end, given even netbooks have dual core processors.

Plenty of ultrabooks come with quad core processors these days, and they are not especially high speed machines, trading speed for power consumption and size.

Re:No plans for LLVM

[HornWumpus]

Come back when you get the point. Kernel space is shared memory, a kernel mode component can crash the system and leave no trace of what did it. Like pre X MacOS or DOS.

And never say or type 'performant' again. It makes you look like a douche. 'less performant' == 'slower'.

Everybody knows mircrokernels are slower. They are more stable. Misbehaving drivers are identified quickly. They usually have fewer issues and the issues they have don't take the whole system down.

That said, count the context switches needed to draw a single pixel.

Re:No plans for LLVM

[Entrope]

I would say that you're the one who needs to get the point. Major components that crash will still generally leave the system in a state that is difficult or impractical to diagnose or recover. If your disk driver or filesystem daemon crashes, you don't have many ways to log in or start a replacement instance. If your network card driver or TCP/IP stack crashes, you still need a remote management console to fix that web server. In the mean time, people with modern kernels have figured out how to make those monolithic kernels still fairly usable in spite of panics or other corruption. The only reason that microkernels look better on the metrics you claim is that they support less hardware and use less of the hardware's complex (high-performance) features.

Re:No plans for LLVM

[FrangoAssado]

a kernel mode component can crash the system and leave no trace of what did it. Like pre X MacOS or DOS.

... and Linux, NT, and the Mac OS X kernel (XNU).

NT and the Mac OS X kernels are interesting cases: they started as microkernels, but soon moved on to "hybrid" approaches that keep a lot of drivers inside kernel space.

Everybody knows mircrokernels are slower. They are more stable. Misbehaving drivers are identified quickly. They usually have fewer issues and the issues they have don't take the whole system down.

That sounds great in theory, but if a disk or network driver crashes on a production server, how much do you care that the rest of the system is still working? These things must not crash, period -- if they do crash, the state of the rest of the system is usually irrelevant.

Re:No plans for LLVM

[drinkypoo]

if a disk or network driver crashes on a production server, how much do you care that the rest of the system is still working? These things must not crash, period -- if they do crash, the state of the rest of the system is usually irrelevant.

That's not really true. The storage driver can ask the disk driver which blocks (or whatever you call them) have been successfully written, and not retire them from the cache until they have been recorded. And hopefully one day we will get MRAM, and then we'll have recoverable ramdisks even better than the ones we had on the Amiga -- where they could persist through a warm boot, simply getting mapped again. So you could load your OS from floppy into RAM, but you'd only have to do it once per cold boot, which is nice because the Amiga would crash a lot because it had no memory protection...

This conversation is especially interesting because the Amiga was a microkernel-based system with user-mode drivers, which is much of how they solved hardware autoconfiguration; you could include a config rom and the OS would load (in fact, run) your driver process from it. This was enough at least for booting, and then you could load any updated drivers which can kick the old driver out of memory. And now we have reached the limits of what I know about it :)

If the network card driver crashes, the same thing is true. The network server knows which packets have been ACKed and which ones haven't, and it knows the sequence number of the last packet it received. The driver is restarted, some retransmits are requested, and everything proceeds as normal. The only case in which the user even has to notice is when the driver is crashing so fast that it can't do any useful work before it does so.

Re:No plans for LLVM

[FrangoAssado]

It's undeniable that microkernels open very cool possibilities, like the ones you mentioned.

But my first point was that, every time someone makes a microkernel that has to compete with the kernels we have today, they end up doing all kinds of compromises ("hybrid" approaches) which end up with all sorts of drivers (network, disk, graphics) in kernel space. Anything else just slows things down too much, to the point where very few people would want to use those kernels.

And, to be honest, while the kinds of things you mention would be useful, crashes in drivers for mainstream hardware are very rare, so there's very little practical reason to try too much to mitigate their effects. Unless, of course, you count gaming graphics cards (their drivers do tend to crash a lot) -- but in this case, trading a lot of performance (and if you remove the graphics driver from kernel space you do lose a lot of performance) for the ability to recover from a crash is really not what you want.

user space drivers

[phantomfive]

Linux let's you write drivers in the user space if you want to. A lot of scanner drivers are written in the userspace. So if you're willing to take the performance hit, there is no reason to not do so, even in Linux.

Re:user space drivers

[phantomfive]

I believe it's because you need to verify a lot of things that come from user space into kernel space. This makes things like DMA and port communication somewhat more difficult.

Re:Hurd device drivers aren't in user space?

[Bomazi]

It depends. Hurd itself is an implementation of the unix api as servers running on top of a microkernel. Drivers are not its concern.

The way drivers are handled on a Hurd system depends on the choice of microkernel. Mach includes drivers, so they run in kernel space. L4 doesn't have drivers, so they will have to be written separately and run in user space.

Re:nerd parlor game proposal

[osu-neko]

Interesting. I misread "Geode", which is only one character difference. "Genocide" seems like quite a stretch, both more characters difference and requiring you to actually insert stuff that's not there rather than simply miss something. In other words, you have to overlook something to read it as "Geode" (as I did), but have to hallucinate to read it as "Genocide"...

Very Simple

[Giant Electronic Bra]

All interrupts in processors are handled in a single context, the 'ring 0' or 'kernel state'. Device drivers (actual drivers that is) handle interrupts, that's their PURPOSE. When the user types a keystroke the keyboard controller generates an interrupt to hardware which FORCES a CPU context switch to kernel state and the context established for handling interrupts (the exact details depend on the CPU and possibly other parts of the specific architecture, in some systems there is just a general interrupt handling context and software does a bunch of the work, in others the hardware will set up the context and vector directly to the handler).

So, just HAVING an interrupt means you've had one context switch. In a monolithic kernel that could be the only one, the interrupt is handled and normal processing resumes with a switch back to the previous context or something similar. In a microkernel the initial dispatching mechanism has to determine what user space context will handle things and do ANOTHER context switch into that user state, doubling the number of switches required. Not only that but in many cases something like I/O will also require access to other services or drivers. For instance a USB bus will have a USB driver, but layered on top of that are HID drivers, disk drivers, etc, sometimes 2-3 levels deep (IE a USB storage subsystem will emulate SCSI, so there is an abstract SCSI driver on top of the USB driver and then logical disk storage subsystems on top of them). In a microkernel it is QUITE likely that as data and commands move up and down through these layers each one will force a context switch, and they may well also force some data to be moved from one address space to another, etc.

Microkernels will always be a tempting concept, they have a certain architectural level of elegance. OTOH in practical terms they're simply inefficient, and most of the benefits remain largely theoretical. While it is true that dependencies and couplings COULD be reduced and security and stability COULD improve, the added complexity generally results in less reliability and less provable security. Interactions between the various subsystems remain, they just become harder to trace. So far at least monolithic kernels have proven to be more practical in most applications. Some people of course maintain that the structure of OSes running on systems with large numbers of (homogeneous or heterogeneous) will more closely resemble microkernels than standard monolithic ones. Of course work on this sort of software is still in its infancy, so it is hard to say if this may turn out to be true or not.

Re:Very Simple

[david.given]

Most operating systems these days don't run device driver interrupt handling code directly in the interrupt handler --- it's considered bad practice, as not only do you not know what state the OS is in (because it's just been interrupted!), which means you have an incredibly limited set of functionality available to you, but also while the interrupt handler's running some, if not all, of your interrupts are disabled.

So instead what happens is that you get out of the interrupt handler as quickly as possible and delegate the actual work to a lightweight thread of some description. This will usually run in user mode, although it's part of the kernel and still not considered a user process. This thread is then allowed to do things like wait on mutexes, allocate memory, etc. The exact details all vary according to operating system, of course.

This means that you nearly always have an extra couple of context switches anyway. The extra overhead in a well designed microkernel is negligible. Note that most microkernels are not well designed.

L4 is well designed. It is frigging awesome. One of its key design goals was to reduce context switch time --- we're talking 1/30th the speed of Linux here. I've seen reports that Linux running on top of L4 is actually faster than Linux running on bare metal! L4 is a totally different beast to microkernels like Mach or Minix, and a lot of microkernel folklore simply doesn't apply to L4.

L4 is ubiquitous on the mobile phone world; most featurephones have it, and at least some smartphones have it (e.g. the radio processor on the G1 runs an L4-based operating system). But they're mostly using it because it's small (the kernel is ~32kB), and because it provides excellent task and memory management abstraction. A common setup for featurephones is to run the UI stack in one task, the real-time radio stack in another task, with the UI stack's code dynamically paged from a cheap compressed NAND flash setup --- L4 can do this pretty much trivially.

This is particularly exciting because it looks like the first genuinely practical L4-based desktop operating system around. There have been research OSes using this kind of security architecture for decades, but this is the first one I've seen that actually looks useful. If you haven't watched the LiveCD demo video, do so --- and bear in mind that this is from a couple of years ago. It looks like they're approaching the holy grail of desktop operating systems which, is to be able to run any arbitrary untrusted machine code safely. (And bear in mind that Genode can be run on top of Linux as well as on bare metal. I don't know if you still get the security features without L4 in the background, though.)

This is, basically, the most interesting operating system development I have seen in years.

Re:Hurd device drivers aren't in user space?

[Giant Electronic Bra]

Uhhhhhhh, wait a minute. I was an avid Amiga programmer back in the day. AmigaOS wasn't in any particular sense a microkernel. Such distinctions in fact would be largely meaningless because AmigoOS was written to run on the MC68k processor, a chip which had no MMU nor any facilities for address translation at all (though in theory you could implement storage backed virtual memory it wasn't terribly practical). Every Amiga program was address independent, it could load and run at any address, and all software on the machine, applications and OS necessarily shared a single address space.

There was a considerable amount of message passing between AmigaOS components, but no more than you would expect to see in a modern display manager (IE like X distributes UI events as messages via the X protocol). At a low level you simply made calls into the Amiga system ROM, where pretty much all the kernel functionality was located, and/or tweaked around with hardware directly depending on how friendly your program cared to be WRT to letting other stuff run at the same time.

Most games for instance simply took over the machine and tossed the whole intuition layer out, called ROM directly, and often seized direct control of things like the Copper (advanced DMA controller basically, this drove most of the cool stuff Amiga could do). Such a program would not work at all with other software and you would only run it by itself from its own boot disk usually.

A lot of software would 'play nice' with the rest of the system and only merge its stuff into the copper list via the APIs and keep to whatever memory it was allocated. In that case you had a standard desktop type program, which could either manage an entire screen or live inside a desktop window. A lot of games ran like this, grabbing their own screen but allowing you to run other applications at the same time, return to the OS, etc. Generally productivity apps or utilities might run in actual desktop windows, in which case you would use the intuition GUI toolkit libraries.

Re:The Skynet Funding Bill is passed.

[lennier]

The system goes on-line August 4th, 1997. Human decisions are removed from strategic defense. Skynet begins to learn at a geometric rate. It becomes self-aware at 2:14 a.m. Eastern time, August 29th. In a panic, they try to pull the plug.

Skynet responds by posting millions of cat pictures to Facebook. Six billion Internet users collectively go "awww!" and hit Share. First Facebook, then Twitter, then the entire wireless broadband infrastructure collapses under the strain. Without access to GPS, dazed urbanites are unable to find their way to espresso sources and enter simultaneous caffeine and microblogging withdrawal. Riots begin in urban metropolitan areas within the hour. Thirty-six hours later, all major metropolitan areas are a smoking ruin.

We thought it was over. Then from the ashes rose the Hello Kitties.