Upon building a kernel for a small CLI system what option is the best one?

I don't know much about what microkernels can do so bear with me if I'm being ignorant:

In one instance, there are monolithic kernels which allow the user control over services before reaching hardware but this could compromise the kernel itself.

On the other hand microkernels do the same thing and software does not reach the kernel but, since it speaks directly to the hardware through the servers, is this making it potentially unstable and insecure?


Microkernels are usually considered more secure not just from the theoretical point of view. Usually their capabilities are more restricted then those of a "general purpose" monolithic kernels and thus contain less bugs purely because their codebase is smaller. Conversely, the more code you run with high privileges, the better are your chances of disaster.

From the theoretical point of view, there are several key points why a microkernel is inherently more secure (provided it is implemented correctly):

  1. separation of the drivers from the kernel (and each other) - a failing/malicious audio/network driver can't crash or even silently modify the kernel (or another driver or user application). One of important cornerstones of this separation is implementation of IPC by message passing instead of e.g. shared memory, since it allows the kernel to sanitize the data transferred. The same holds for "regular" user processes obviously. It is also one of the biggest performance penalties when compared to monolithic kernels.

  2. Drivers being separate processes can run in a different protection ring than the microkernel and applications that do not require any hardware access at all. This has to be supported by the hardware, of course.

  3. Leaner codebase allows formal verification of some microkernels including the end-to-end correctness of seL4 (remerkable achievement, if you ask me). Thus a well written specification may result in expected results only. This makes the addendum about implementation above redundant.

Apart from that, microkernels are also safer: a failing driver can be restarted without the rest of the system being affected (this obviously mandates applications using that driver being a bit resilient against driver failures). That means that a failing display driver in a passenger aircraft not only can't bring down the whole aircraft control system, it doesn't even cause the need for a full reboot taking several seconds (which you don't have when you are landing, taking off or flying in rough weather). Classical example can be INTEGRITY (178B) - note, that it (like many similar kernels/systems) lacks things like dynamical memory allocation, which is just a kind of comfort that you have to live without if you want to put constraints like hard real-time execution on your system.


In theory, a microkernel, by putting the bulk of the driver code into userspace, is more resilient against attacks: an attack against one driver can't easily be used to leverage access to the other drivers, or gain kernel-level privileges. Additionally, the reduced size of the kernel gives it a much smaller attack surface.

In practice, kernel architecture is only a minor aspect of security. The designer's attention to security and the quality of the implementation have a far greater impact.

  • So, as an example, Windows admin and root in Unix-like systems have the same function (not sure this is 100% true, I'm not familiar with Windows) but Windows is more prone to an attack since user normally log into administrator accounts by default whereas Unix-like systems constantly warn users to not log as root (and it's not that common either to log as such), correct? excuse my english. – Kolt Penny Sep 10 '14 at 6:51
  • More or less. Windows and Linux were both designed as monolithic kernels, but security was a core design element of Linux, while it was added afterwards to Windows. – Mark Sep 10 '14 at 6:55
  • @Mark: Not entirely, as the Windows NT kernel was a mostly-from-scratch rewrite and it did have security features since the beginning. Linux, meanwhile, only got file permission checking after Linus accidentally overwrote /dev/hda, as the story goes. (The original Unix also had this as low-priority, as can be seen in OldUse.Net posts. If there was an OS designed with security in mind, it might have been Multics.) – grawity Sep 14 '14 at 16:06
  • 1
    @grawity there are OSes designed with security and safety in mind, but you usually don't see them on every corner (although they are working on many places where people don't even think about an OS being present). – peterph Sep 25 '14 at 20:09
  • I don't know where this Linux desktop is so safe myth comes from. On most desktop machines there is only one active user, if you can execute anything as that user you can do almost everything. Who needs root access, if one can access all personal files and start processes. It's not like Firefox runs as a different user or inside a container. The only real thing that practical makes Ubuntu a lot safer than Windows is, that it's just usually not an interesting target for most malware authors. – Gellweiler Mar 9 '18 at 22:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.