Ask HN: Are advances in AI going to push Linux to a micro-kernel?

[cayleyh]

This is something that has been bouncing around my head for the past couple weeks with the flood of security related news around Mythos and the number of 0days being found.

Microkernels, unikernals, hardware-enforced capabilities are all technical approaches to limit the attack surface area and blast radius of bugs. They seen to have had limited penetrate the current Linux-based VM / Container / VPC provider stacks a lot of us (most of us?) are using for production environments. The huge Linux ecosystem it's probably more of a driving factor than overall performance at this point, the Linux performance compared to systems that use these approaches was a driver in the past.

If the pace of advancement in using LLMs and coding agents to find and exploit bugs continues, do you think that Linux will need to adapt the approaches it uses to be able to limit the impact of bugs in drivers and other ancillary code? Do you think that alternative approaches like Unikernals will be a beneficiary of the advancement instead? Or do you think Linux just has too much developer manpower and ecosystem strength that is will mostly just adapt through the "rough patch" but remain mostly unchanged structurally afterwards?

Interested, hear what other people think could be a reasonable response if LLMs continue to get better at finding and exploiting software bugs.

[RetroTechie]

Imho turning Linux into a microkernel + a grab-bag of drivers etc, would be wise at this point. Security advantages outweigh (perceived) performance impact for most uses.

Many pieces are already in place. See eg. L4Linux, seL4, Genode, various types of hypervisors etc.

But it would require defining stable interfaces between many moving parts which are currently in-kernel. Which in Linux land... is not a thing. Changing that would need consensus between an overwhelming majority of kernel developers.

So you could say: inertia, and the plethora of virtualization / isolation options are "good enough" for most users.

As for AI mass-discovering bugs: just a temporary rough patch (no pun intended). Linux is a massive codebase. But a lot of it is high-quality, and the # of bugs hiding in there is finite. The ceiling is not in how powerful AI becomes, it's the (finite) # of pre-existing bugs. So at some point it'll be back to a situation where only new code can bring in additional bugs. Probably AI will help there too.

Also note that the bulk of Linux is driver code for various hardware & technologies: system busses, memory management, file systems, disk caching, networking stacks, encryption, GPU, sound, etc etc. A lot of code may never be loaded or executed, bugs in there not applicable, system not vulnerable. Okay: maybe not a safe assumption. But often true nonetheless. EDIT: oh and not all bugs are vulnerabilities.

[cayleyh]

A compounding problem is that lots of the key drivers depend on binary blobs provided by the vendors, making updating and porting that much harder. I know there has been some work to have translation layers between "linux driver api surface" --> "other OSs" but that feels problematic to trust & maintain unless it's driven from the linux kernel team itself.

[snvzz]

The microkernel-based systems (LionsOS, Genode and so on) already have sane interfaces.

What is needed in that regard is just to port more drivers over.

[wmf]

You don't need stable interfaces in a monorepo.

[BlueRock-Jake]

Spent a couple years essentially building exactly that at BlueRock. We had a partially formally verified microkernel that we would insert between the hardware and OS to intercept system calls. Under 10,000 lines of code by design, deployed in some very high-security environments.

Funnily enough we had to pivot to securing agentic AI (with a few pit stops along the way) because it was an extremely hard sell. We needed access to bare metal and the pitch to teams to allow us to do that was excedingly hard. Now, we've pretty much come full circle.

I believe AI could push people to look at securing Linux structurally but its hard for me to imagine they overcome the inertia we faced. Does bring up other interesting questions about AI-assisted formal verification, which even saying sounds weird. If you can verify a narrow slice of the call chain cheaply, you don't need to solve the whole kernel.

One more thing in regard to AI, the deployment model is shifting. Running agents on laptops is increasingly the wrong pattern. As they move to server infrastructure with real credentials and network access, the relevant security question changes too. Perimeter controls don't follow the workload, which is what's needed. The kernel approach addresses that but so does living/enforcing inside the execution itself.

[kspetkov79]

The microkernel argument makes sense in theory, but the real bottleneck has always been driver complexity. If LLMs can reliably generate verified drivers with formal correctness guarantees, that changes the equation significantly. Until then, Linux's ecosystem inertia wins every time.

[snvzz]

Drivers need to be updated every now and again due to the lack of stable APIs, and increasingly nobody wants to deal with that.

The resulting trend is drivers for older/less common hardware are being dropped.

Linux complexity comes with a huge cost. At some point, the overhead is such that it'd be easier to start over.

I would argue we're long past that point. But inertia is a bitch, and insane money is being poured on Linux with little to show for it, just because.

Fortunately, seL4 foundation is picking up momentum, with large companies joining every year. There is some hope in the horizon.

[bigbadfeline]

> But inertia is a bitch, and insane money is being poured on Linux with little to show for it, just because.

Or maybe because just like C++ Linux has reached the point of no return, no amount of LLMs can save it, big money is the whole reason for its existence.

A replacement can come soon enough.

[cayleyh]

seL4 + linux kernel api shims does seem like the most realistic approach to move forward. But the driver + driver API situation seems like the biggest barrier.