HN

Comments (51)

• scottlamb
  This is the second unikernel article this week I think, and the second that really undersells the benefits of having a full OS. Let's just swap out a couple of words:> With a unikernel, the [observability] surface is much smaller. If the functionality isn't in the application (the operating system), then the [SRE] is screwed. There's no next hop.Tools such as `strace`, eBPF, `lsof`, `ss`, etc. have tremendous value. The article mentions some nice things for observability ("structured logging, OTel") but so much gets thrown away.
• Menu

  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?
• Menu

  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.https://baremetal.returninfinity.com
• Meleagris
  Totally agree with this article. With AI, I think now is the perfect time to consider where Unikernels might fit into your architecture, and how you can leverage them to minimize your attack surface.I’ve started looking at them myself, and have been comparing them to mature VMMs like Firecracker, and asking myself where each piece of my stack might be best run.Virtual machines and containers are no longer an effective isolation mechanism when AI is involved. VM breakouts are becoming trivial. So everyone should be considering how to bake better security into the their runtimes.
• Menu

  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...
• Menu

  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
• anon
  undefined
• 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)
• Menu

  eyberg
  Reducing attack surface is definitely a plus but it is nowhere close to the number one security benefit of running unikernels.That's why I never really liked talking about "reducing attack surface" that much because folk inevitably turn to lines and code, which while reducing is good, just simply doesn't communicate what the biggest problem truly is.Vuln exploitation is the number one entry point for data breaches and os command injection is the number one CWE in CISA Kev from last year.System intrusion was repeated something like 64 times in last year's DBIR.The operating system itself is literally the problem as it's inherently meant to run many different programs whereas unikernels only run one.
• sroerick
  I've been using OCaml for a couple of years now but haven't dug into Mirage yet. It is super cool. Loved the anecdote about Yaron. Vibecoding in OCaml feels like a superpower. Adding Oxcaml and having your whole company on that must feel very good.
• Menu

  terabytest
  I’m completely ignorant about this and likely just missing the point but: isn’t the point of an OS to not have to (vibe)code filesystems and networking by hand every time you need them? Also, how does a unikernel cooperate with other applications? Would they all live in separate networked unikernels managed by a hypervisor? And, if they all (vibe)coded their own fs and network wouldn’t that introduce subtle bugs and inconsistencies that would eventually bring the whole thing down and lead you back to the need for shared primitives in the first place?Maybe a good halfway point is to still have a unikernel but the libraries for common stuff like networking or fs are already written according to a standard and plug and play and reusable across applications?
• Menu

  za_creature
  The only time you didn't lie was when mentioning seL4.You're Linus arguing against Tanenbaum. Even if you win, you still lose.
• Menu

  lasiotus
  Unikernels are on the smaller side of the spectrum; Linux on the larger side, with a lot of room in the middle...
• nickpsecurity
  The two choices offered are a false delimma. The MILS kernels that came before seL4, like INTEGRITY RTOS and LynxSecure, had middleware to make deplpyments easier. The open-source solutions mixed standalone apps with user-mode VM's for Linux compatibility. OKL4 let one use drivers across them.Looking at what's out there, I think GenodeOS should be mentioned for application-specific systems. They can even build some of their stuff on seL4 if you want.https://genode.org/I'll also add there's been unikernel projects that aren't in exotic languages. Even C++ (IncludeOS?). There's probably one in Rust by now. If not, it could probably build on Redox's components.
• Menu

  jauntywundrkind
  I do wonder what kind of wins we're going to see from unikernels.I used to regard V8 Isolates as a best possible sort of technology, with userlands juggling lots of processes.Seeing netlify & unikraft switch to microvm's and have such a huge speed up was a bit of an awakening for me. Those are really fast start times! https://www.netlify.com/blog/edge-functions-firecracker-micr... https://unikraft.com/customer-stories/edge-functions-netlify...Intuitively, I think I have some appreciation for how much silicon has been poured into virtualization. Its always seemed like a "yeah but you could avoid those costs by not doing that" but I'm more receptive to the idea that these might in some cases be really good ways to get some of the isolation workloads demand with the hardware helping us out, these days. There's so much securing for vm's, and maybe it's just easier than trying to secure in userlands: let the hardware help.Long time interest in microvm's but they felt heavier weight than I wanted. Now it feels like maybe they might actually in some regards in some ways be lighter weight than managing workloads yourself in userland. Maybe. I dunno. Interesting times, i'm open to it.Edit: I just chatted with Astra Pro some about these ideas, if anyone wants some sense material to chew on. https://chatgpt.com/share/6aca924c-8e64-83ea-a5c3-aae08b2cdf...
• Menu

  jongjong
  I was thinking that we don't need programs to share CPUs anymore now that each machine has so many of them. We could have an OS which binds each program to one CPU. When it runs out of CPUs, it suggests to close an existing program. Then programs don't need to pay context-switching cost.