--- title: Maybe we should revisit microkernels | daily.dev description: Modern hardware, specifically IOMMUs (Input-Output Memory Management Units), may finally make microkernels viable after decades of being dismissed due to... canonical: https://daily.dev/posts/maybe-we-should-revisit-microkernels-cmgztphch twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: Maybe we should revisit microkernels | daily.dev og:description: Modern hardware, specifically IOMMUs (Input-Output Memory Management Units), may finally make microkernels viable after decades of being dismissed due to... og:url: https://daily.dev/posts/maybe-we-should-revisit-microkernels-cmgztphch og:image: https://api.daily.dev/og/posts/CMGZtphCH.png og:image:alt: Maybe we should revisit microkernels og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # Maybe we should revisit microkernels **[Lobsters](https://daily.dev/sources/lobsters)** · 4 min read · 0 upvotes · 0 comments ## Summary Modern hardware, specifically IOMMUs (Input-Output Memory Management Units), may finally make microkernels viable after decades of being dismissed due to performance overhead. In a microkernel OS, everything except scheduling, I/O management, and IPC runs in userspace, offering better security, reliability, and modularity. The CrowdStrike incident is cited as an example of how a microkernel would have contained the damage. With IOMMUs now standard in virtually all PCs, userspace processes can directly access hardware devices, eliminating the costly context switches that killed microkernel performance in the 80s and 90s. Zero-overhead IPC is achievable via shared memory ring buffers with atomic operations, a pattern already used in GPU drivers. A practical implementation could leverage Xen for the hypervisor layer, FreeBSD server code for network/filesystem, and Linux's DRM subsystem for graphics. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Community take How the wider developer community reacted, aggregated from 2 discussions and 43 comments across lobsters, hackernews (as of 2026-07-26). **TL;DR:** The community broadly agrees that microkernels have real theoretical advantages but remain hampered by IPC/context-switch overhead and ecosystem inertia; several commenters push back on the article's historical framing, noting that modern L4-family kernels have already solved many of the performance problems the post attributes to microkernels generically. **Sentiment:** 20% positive · 50% mixed · 30% skeptical **The case for** - Modern L4-family microkernels (QNX, seL4, Fuchsia, Redox) have demonstrated that Mach-era IPC overhead is not inherent to the microkernel model. - Isolating drivers as separate processes can meaningfully improve fault recovery — e.g., resetting a crashed GPU without a full reboot. - Shared-memory async queue designs (similar to io_uring) can make microkernel IPC competitive with monolithic syscall paths. - Statically-defined microkernel systems offer a compelling security model by separating administration from everyday use. **The pushback** - Context-switch costs per packet/request remain a fundamental bottleneck at high network speeds (25–100 GbE), regardless of IOMMU availability. - No existing microkernel provides a smooth migration path for legacy Linux applications and drivers, limiting adoption. - The article's claim that IOMMU availability changes the microkernel performance story is disputed — the real historical problem was inefficient IPC, not hardware access. - Reliability benefits are overstated: a compromised filesystem or GPU driver can still bring down dependent workloads, and defensive inter-process code inflates complexity. - L4-based systems like Genode on seL4 still struggle with real-world dynamic workloads (e.g., running a Linux VM is painfully slow). - The article omits memory management / MMU control as a core microkernel responsibility. **By community** - lobsters (mixed): Discussion is technically rich, focusing on L4/seL4 real-world performance, async shared-memory IPC design, and the niche of static vs. dynamic microkernel deployments, with generally skeptical but nuanced takes. - hackernews (mixed): Commenters debate whether the article's historical framing is accurate, with strong pushback that L4 already solved Mach's overhead and that the claimed security/reliability upsides are unproven in practice. **Hottest debate:** Whether microkernel security and reliability benefits have actually been proven in practice, or whether history shows they fail to materialize while adding complexity. **Open questions** - Can a microkernel ever provide a Linux-compatible syscall and driver API to enable gradual migration of legacy software? - How do async shared-memory queue designs (io_uring-style) change the real-world performance gap between microkernels and monolithic kernels at high network speeds? - What is the future of Fuchsia, and does its apparent decline validate or refute the microkernel adoption argument? - Does running drivers in userspace actually prevent whole-system failure when a critical subsystem (filesystem, GPU) crashes? **Highlights** > More precisely: let's say you're running 12Gb/s ethernet (basically 10 but it makes some head-math easier). This is about 1.5GB/s, and for 1500 byte packets that's about 1 Mpps (million packets per second). On a ~3GHz CPU, that gives you around 3000 cycles to process each packet without batching. Just memcpy without batching comes with issues, as (assuming non-cache-coherent DMA) main memory accesses on the order of [100+ cycle latencies can easily exceed the actual time to memcpy one packet](https://www.sigarch.org/fast-memcpy-a-system-design/) and that's 10% of your CPU utilisation gone already. Doing all the packet processing inside the kernel means you pay less of the address-switch costs, but you still pay the mode-switch costs (easily another few hundred cycles on modern x86_64 processors) to go to the application. Yes, ping-ponging a singular packet through several user-level processes and then a response back is going to never work. But that's the same reason you don't design a web server that processes a single request at a time. You can probably get away with processing a single packet in 3000 cycles if all you do is a UDP echo server, and driver, and multiplexer, but at that point you're spending most of your time context switching. Bump network speeds up to 25Gbe or even 100Gbe and now you have 300 cycles, and (still assuming one CPU) now you have no headroom, even if you only ever need to stay in kernel space. Of course, anyone who needs the absolute lowest latency where the delay of batching is an issue tends to use full kernel-bypass stacks where you utilise a full core polling, and a full core running an application and everything in shared memory, then you're not paying any context switching costs. But that's *easier* in a microkernel, because your network (& drivers) already (usually) live in userspace, and your interrupt handling path is faster because the micro-ness of the microkernel causes less cache pollution - although likely you're not even using interrupts and never need to drop into the kernel. > — [juliaaa on lobsters · 1 points](https://lobste.rs/s/krsvrp/maybe_we_should_revisit_microkernels#c_lgf2d2) > Ioperm, which was introduced by 80386 in 1985, is useful only for a few legacy peripherals. It allows the operating system to allocate peripherals mapped in the special I/O address space to dedicated device driver processes. For example it could allocate the real-time clock to such a process and a serial UART interface to another process. Most modern peripherals are memory-mapped. However, you are right that even on the older systems without an IOMMU, the operating system could allocate peripherals to separate device driver processes, using the standard CPU MMU and mapping the peripherals using appropriate page attributes, e.g. as uncacheable memory regions. The IOMMU is not needed to protect the OS and the processes between themselves, but it is needed to protect both the OS and the processes from rogue peripherals. This is needed regardless if the kernel is monolithic or a microkernel. The microkernel overhead in the old microkernels, like Mach and all those inspired by it, was indeed too high due to context switches, but that has nothing to do with microkernels but those microkernels just implemented an extremely inefficient method of IPC, which unfortunately has tarnished the reputation of microkernels. The only right form of IPC does not use any context changes, i.e. it uses message queues located in shared memory pages, with zero copying and no context changes, which is much faster than the traditional syscalls used with monolithic kernels. In TFA there is another thing with which I do not agree, it is said that message queues need atomic CAS (compare-and-swap, a.k.a. compare-and-exchange in Intel parlance). In my opinion, using CAS for implementing message queues is a big mistake, because this instruction is non-deterministic and the execution time for any program that uses CAS is unbounded for the worst case. One-to-one message queues do not need any atomic instructions, they just need store-release instructions and either wait-for-not-equal loops when the waiting times are expected to be short or futex_wait (or similar) syscalls when the waiting times are expected to be long. Waiting for (multiple) events is one of the principal functions that must be implemented by a microkernel for enabling interprocess communication, together with a memory mapping API. IPC per se must not be implemented by the microkernel, but by user-space libraries. The message queues that are many-to-one, one-to-many or many-to-many, can use the atomic fetch-and-add instruction (LOCK XADD on x86-64), to dynamically partition the queue, allowing the concurrent insertion and extraction of data into/from the queue by all communicating processes. In this case, only the updating of the queue pointers is serialized, resulting in very low overheads for the communication through the message queue, even in cases of high contention. While I agree with you that TFA is incorrect in some details, I agree with the general idea that today one could implement microkernels that would be simultaneously faster and safer and easier to maintain than a monolithic kernel like Linux. Nonetheless, the chances for such a microkernel to appear and to be successful are very low. The reason is that the only way to be successful would be to implement a very easy transition to it from one of the popular OSes, e.g. from Linux. This means that it would have to also implement a syscall interface completely compatible with that of Linux, to allow running unmodified legacy programs, and also a device driver API compatible to that of Linux, to allow the reuse of the existing device drivers. Probably the easiest way to do this would be to start from Xen, still using the root Xen domain with a Linux kernel that manages the I/O, and running legacy Linux applications in virtual machines. From this, another special domain with the new microkernel should be added, and then the peripheral handling should be migrated gradually from the Xen Dom0 Linux to the microkernel with its associated > — [adrian\_b on hackernews · 2 comments](https://news.ycombinator.com/item?id=49056402) > > history has proven What history? What proof? What evidence? What commercial microkernel systems are you referencing that suffer from trivial LPEs? Or whole system DoS from unprivileged code execution? To the extent that you argue your alleged failure modes are fundamental. > none of the upsides have panned out Again, what history? What proof? What evidence? One of the stated upsides relative to monolithic kernels is superior reliability. There are numerous microkernels reliable enough for usage in critical flight systems. None of the standard commercial monolithic kernels are even in the vicinity of that. Another of the stated upsides is superior security. There are multiple microkernels secure enough to be platforms for systems that need to be secure against state actors. None of the standard commercial monolithic kernels are even in the vicinity of that. History has proven the opposite of your claims. The concrete evidence is the opposite of your vague unsupported assertions. > — [Veserv on hackernews](https://news.ycombinator.com/item?id=49061279) > I think history has proven that this theory: > Better security, better reliability, better modularity. Better security because in a muicrokernel [sic] system a bug in one driver only gives an attacker access to that subsystem (or maybe even that driver), as opposed to having unlimited access to the whole system like is the case with mainstream operating systems today. Better relaibility [sic] becasue [sic] a crash in one subsystem only crashes that subsystem instead of crashing everything; if windows were a microkernel system then the crowdstrike bug would have just stopped some IT security staff from getting telemetry instead of being front page news. If linux were a microkernel system then the linux kernel team wouldn't be responsible for merging every driver for every hardware device, and wouldn't be responsible for vetting code that they would have to become experts on the inner workings of every chip supported by the linux kernel to properly vet. Is false. In particular: - A kernel-level exploit can almost always be escalated. If I control your filesystem, you're SOL - A kernel-level crash in any subsystem brings down the whole system. If your file system crashes, or your GPU is in an unstable state, there is no coming back - Modularity is a question of clear boundaries. Whether those are static linking, dynamic linking, or XML-RPC doesn't change the level of modularity. And so on. Basically, none of the upsides have panned out. On the other hand, code complexity explodes. Microservices need to know who to call how. The whole "a crash in one subsystem only crashes that subsystem instead of crashing everything" means every subsystem needs defensive code for things going wrong elsewhere. KLOCs go up, bugs/KLOC stay constant, and things get less stable. Plus, it's hard to reason about systemically, and without excellent telemetry, neigh-impossible to debug. > — [frognumber on hackernews · 4 comments](https://news.ycombinator.com/item?id=49056793) > My experience was, it didn't. Years ago, a buddy and me got way excited about the elegance of microkernels and QNX in particular. We had a problem to solve in image processing that involved firewire. The code was simple and cool. And it was dismally slow. We picked up the 1394 driver for Linux at the time, added isochronous support using DMA to it (took about 12 hours) and were off to the races. We were relatively new to Linux as well at the time, and it was early enough that there were skeptics in the company about using something like Linux for our optical sorting machines. This event changed that. I remain of the belief that the ideals behind QNX/microkernels, and message passing, are awesome, but to take hold at that level, something has to be done to make the message passing of data between processes way cheaper. Ironically, I do web applications with Elixir these days, where I enjoy all the same process isolation as QNX advertised. I just don't care a lot about the performance (e.g. I'm not doing optical processing), because if I did Elixir/BEAM has the same data copying issues. > — [travisgriggs on lobsters · 2 points, 1 comments](https://lobste.rs/s/krsvrp/maybe_we_should_revisit_microkernels#c_xvi7ra) **Source threads** - [lobsters](https://lobste.rs/s/krsvrp/maybe_we_should_revisit_microkernels) · 44 points · 21 comments - [hackernews](https://news.ycombinator.com/item?id=49054908) · 5 points · 22 comments ## Similar posts on daily.dev - [Hackaday Europe 2026: Fluid Kernels And Optimizing C\+\+ For MCUs](https://daily.dev/posts/hackaday-europe-2026-fluid-kernels-and-optimizing-c-for-mcus-qwo7s670n) · Hackaday · 0 upvotes · 0 comments - [Linux VM without VM software - User Mode Linux](https://daily.dev/posts/linux-vm-without-vm-software---user-mode-linux-pcdpcizhy) · Hacker News · 2 upvotes · 0 comments - [AMD Revives Linux Kernel Patches For Hardware-Accelerated vIOMMU](https://daily.dev/posts/amd-revives-linux-kernel-patches-for-hardware-accelerated-viommu-vze44shtf) · Phoronix · 0 upvotes · 0 comments - [Your Container Is Not a Sandbox](https://daily.dev/posts/your-container-is-not-a-sandbox-dkskd3kl8) · Lobsters · 26 upvotes · 1 comments - [Kubernetes finally lands user namespace support, but shared kernel problem remains](https://daily.dev/posts/kubernetes-finally-lands-user-namespace-support-but-shared-kernel-problem-remains-9xddjusia) · The New Stack · 4 upvotes · 0 comments --- [View this post on daily.dev](https://daily.dev/posts/maybe-we-should-revisit-microkernels-cmgztphch) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"Maybe we should revisit microkernels","url":"https://daily.dev/posts/maybe-we-should-revisit-microkernels-cmgztphch","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/maybe-we-should-revisit-microkernels-cmgztphch"},"datePublished":"2026-07-26T07:43:13.263Z","dateModified":"2026-07-26T21:15:37.713Z","description":"Modern hardware, specifically IOMMUs (Input-Output Memory Management Units), may finally make microkernels viable after decades of being dismissed due to...","image":"https://media.daily.dev/image/upload/s--VDukGCjf--/f_auto/v1722860399/public/Placeholder%2002","thumbnailUrl":"https://media.daily.dev/image/upload/s--VDukGCjf--/f_auto/v1722860399/public/Placeholder%2002","isAccessibleForFree":true,"articleSection":"Lobsters","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"Lobsters","logo":"https://media.daily.dev/image/upload/s--tl8v_Fku--/f_auto,t_logo/v1698841318/logos/lobste.jpg","url":"https://daily.dev/sources/lobsters"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/maybe-we-should-revisit-microkernels-cmgztphch","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":0},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"","timeRequired":"PT4M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Lobsters","item":"https://daily.dev/sources/lobsters"},{"@type":"ListItem","position":3,"name":"Maybe we should revisit microkernels"}]} ```