Unikernels Were Hard—Until AI Made Them Easy
Unikernels were hard. key word: were
Geoffrey Huntley talks with Justin Cormack about why unikernels failed a decade ago and why they're suddenly practical. The old friction—missing libraries, storage, and tooling—is now a prompt away. Huntley built a distributed unikernel OS in a week, porting Orleans to OCaml, and argues that removing the shell and interpreter turns drive-by exploits into targeted attacks. For security, he says, you have two choices: seL4 or unikernels.
If you have to tool-call a human, also known as "Dear Maintainer", who might be on holiday or might have abandoned the project, and wait a day, two days, or even five minutes, that's not AGI.
- RantyDave
I've had limited adventures in embedded software and as part of that became a fan of Zephyr (http://www.zephyrproject.org) and wonder about its potential application as a unikernel.
On the plus side: it's a unikernel. You compile it and your application together and get a binary. It has support for running on virtual hardware (https://docs.zephyrproject.org/latest/hardware/virtualizatio...) and virtio is the new bios, right?
On the minus side: I think porting "traditional" software - say Nginx - to it will be agonising. And I can't make any guarantees about its performance in the same way that Alpine Linux container images are not necessarily fast.
But there's an entire toolchain, debugging story, drivers etc. for something that compiles to tiny and starts up basically instantaneously. Surely that's got to be useful for something?
- ianseyler
It’s good to see this! I’m offering a cloud service to host unikernels based on my BareMetal kernel.
~$0.005 CAD/h for a small network-enabled VM with 4MiB of RAM and no disk.
- scrubs
A natural r&d project would be a high frequency oms or something like an nyse bid/ask/match book manager.
These apps tend to do kernel bypass anyway for net i/o after hard scrubbing the os to remove as many interrupts and other superfluous jitter the oms does not need.
However, I believe the low level kernel bypass code (eg dpdk, libfabric) depend on Linux to talk to the hw in a disciplined way.
Anybody know better?
A decently faster oms this way could be a practical alternative to fpgas we sometimes see in that space. (hw would be co-located of course)
- angry_octet
If you have serious attack surface minimisation goals you need to embrace FOGAs. LLM coded unikernels have way too much bloat.
The Zynq UltraScale+ parts pair a hard ARM CPU with FPGA fabric. You can progressively isolate fast path and high security components in logic. LLMs are getting quite good at using synthesis tools.
https://www.amd.com/en/products/system-on-modules/kria/k26/k...
- vsgherzi
As mentioned before on this topic. What about debug ability? An application overflow now corrupts part of the network stack.
In an oxide episode there were some mentions of reading off data lines but I just don’t think that’s practical.
The reduced attack service is cool but not at the expense of my visibility and liveness of the system