eyberg

Agreed. The vast majority of prod workloads are persistent services that we want running 24/7.

> I do wonder what kind of wins we're going to see from unikernels.

I come from security so I'm more disposed towards the benefits thereof, however, being a person that has had a commercial and open source unikernel presence for a while now - "ease of use" is probably the largest selling point that I see from most of our user base. There is nothing out there that gives you the performance, security and cost benefits from shipping your unikernels to AWS, GCP, etc. in seconds. Not lambda, not cloudflare, not any of the millions of microvm providers. You quote netlify right here (who actually don't use unikernels per-se but small little linux vms (big difference!)) but why would you even use them when you can do it cheaper by shipping straight to ec2?

That's what unikernels allow you to do.

Honestly, I think there is a lot of similarities between unikernels, at least the one I'm active with and qubes. The big difference to me is that qubes is more desktop/consumer focused and nanos (the one I'm involved with) is more server-focused but the same sort of ideology/principles gets exposed - just at varying levels and because of the end environment they get architected differently.

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.

Containers and security are oxymorons. The flood of page cache cves (which can always be escalated/weaponized to an escape) from the other month is making deploying containers to prod untenable.

As for orchestration - a lot of folks think you need a completely new orchestration system for dealing with vms but we just simply re-use the existing infrastructure that already exists - the public clouds. Those companies have tens of thousands of engineers that are much better than the average engineer at this stuff, custom hardware, custom protocols and close to several decades of existing deployment.

I can build and ship a vm from my laptop/ci to prod on AWS/GCP in ~tens of second. Granted I come from the camp that thinks deploying full blown general purpose operating systems to prod is an increasingly incredibly risky practice.

So first off - NVD has been sliding for a long time now. This has nothing to do with mythos. The amount of money that goes into this program for the output is straight up criminal.

For a very long time the security world has basically given up on defense and relies on prioritizing cves. This is wrong on so many different levels.

a) You can't scan for things you don't know that exist.

b) Malware, like all the supply chain issues in the past few months don't have cves to begin with but they are still massive security issues. That is to say the cves themselves don't really address everything. So you end up with IOCs but those are also totally worthless if it's the first time you are seeing something. You have to have proactive defense if you actually care.

c) There are quite a few cwes that you can outright prevent through various defensive means but for whatever reason organizations won't. This is an organizational issue - not a technical one. This might be one of the main benefits of the cve program in that it starts to penalize organizations through insurance and other means by tracking it and this is exactly how a lot of the security world operates.

I'm cautiously optimistic that the world is going to start looking at stronger proactive defensive measures rather than relying on this reactive scanning approach.

No they have not been. There were at least 16 container escapes last year - at least 8 of them were at the runtime layer.

I personally spent way too much time looking at this in the past month:

https://nanovms.com/blog/last-year-in-container-security

runc: https://www.cve.org/CVERecord?id=CVE-2025-31133

nvidia: https://www.cve.org/CVERecord?id=CVE-2025-23266

runc: https://www.cve.org/CVERecord?id=CVE-2025-52565

youki: https://www.cve.org/CVERecord?id=CVE-2025-54867

Also, last time I checked podman uses runc by default.

Except this is very clearly running linux.

The majority of nanos users don't do either of these methods. They simply create the image (in the case of aws that's an ami) and boot it. This is part of what makes them vastly more simple than using normal linux vms or containers as you don't have to manage the "orchestration".

A lot of these "ai sandbox" conversations target code that is already running in a public cloud. Running firecracker doesn't give you magical isolation properties vs running an application in ec2 - it's the same boundary. If you're trying to compare to running multi-tenant workloads in containers on the same vm vs different tenants on different vms - sure that's an improvement but no one said you had to run containers to begin with.

Furthermore, running lots of random 3rd party programs in the same instance, be it a container, or an ec2 vm, or a firecracker vm all have the same issues - it is inherently totally unsafe. If you want to "sandbox" something you need to detail what exactly you are wanting to isolate.

A lot of people might suggest not being able to write to the filesystem, read env vars, or talk over the network but these are table stakes for a lot of the workloads that people want to "isolate" to begin with.

So not only is there this incorrect view that you are isolating anything at all, but I'm not convinced that the most important things, like being able to run arbitrary 3rd party programs, is even being considered.

No they are not. The "industry" totally disagrees with this statement as well.

> Escaping a properly set up container is a kernel 0day.

Not it is not. In fact many of the container escapes we see are because of bugs in the container runtimes themselves which can be quite different in their various implementations. CVE-2025-31133 was published 2? months ago and had nothing at all do with the kernel - just like many container escapes don't.

Duplicating a networking and storage layer on top of existing storage/networking layers that containers, and the orchestrators such as k8s provide, absolutely degrade performance - full stop. No one runs containers raw (w/out an underlying vm) in the cloud - they always exist on top of vms.

The problem with "container" security is that even in this thread many people seem to think that it is a security barrier of some kind when it was never designed to be one. The v8 sandbox was specifically created to deal with sandboxing. It still has issues but at least it was thought about and a lot of engineering went into it. Container runtimes are not exported via the kernel. Unshare is not named 'create_container'. A lot of the container issues we see are runtime issues. There are over a half-dozen different namespaces that are used in different manners that expose hard to understand gotchas. The various container runtimes decide themselves how to deal with these and they have to deal with all the issues in their code when using them. A very common bug that these runtimes get hit by are TOCTOU (time of check to time of use) vulns that get exposed in these runtimes.

Right now there is a conversation about the upcoming change to systemd that runs sshd on vsock by default (you literally have to disable it via kernel cli flag - systemd.ssh_auto=no) - guess what one of the concerns is? Vsock isn't bound to a network namespace. This is not itself a vulnerability but it most definitely is going to get taken advantage in the future.

A shell by design is explicitly made to run other programs. You type in 'ls', 'cd', 'cat', etc. but those are all different programs. A "webshell" can work to a degree as you could potentially upload files, cat files, write to files, etc. but you aren't running other programs under these conditions - that'd be code you're executing - scripting languages make this vastly easier than compiled ones. It's a lot more than just slapping a heavy-handed seccomp profile on your app.

Also merging the address space is not a necessity. In fact - 64-bit (which is essentially all modern cloud software) mandates virtual memory to begin with and many unikernel projects support elf loading.

We don't enable that exec-protect feature on by default explicitly for this reason. You are right - jit needs it.

Let's see last month (November 2025) we had CVE-2025-31133, CVE-2025-52565, and CVE-2025-52881 alone. Container breakouts happen almost monthly.

I can't speak for all the various projects but imo these aren't made for bare metal - if you want true bare metal (metal you can physically touch) use linux.

One of the things that might not be so apparent is that when you deploy these to something like AWS all the users/process mgmt/etc. gets shifted up and out of the instance you control and put into the cloud layer - I feel that would be hard to do with physical boxen cause it becomes a slippery slope of having certain operations (such as updates) needing auth for instance.

To be clear there are still numerous attacks one might lob at you. For instance you if you are running a node app and the attacker uploads a new js file that they can have the interpreter execute that's still an issue. However, you won't be able to start running random programs like curling down some cryptominer or something - it'd all need to be contained within that code.

What becomes harder is if you have a binary that forces you to rewrite the program in memory as you suggest. That's where classic page protections come into play such as not exec'ing rodata, not writing to txt, not exec'ing heap/stack, etc. Just to note that not all unikernel projects have this and even if they do it might be trivial to turn them off. The kernel I'm involved with (Nanos) has other features such as 'exec protection' which prevents that app from exec-mapping anything not already explicitly mapped exec.

Running arbitrary programs, which is what a lot of exploit payloads try to achieve, is pretty different than having to stuff whatever they want to run inside the payload itself. For example if you look at most malware it's not just one program that gets ran - it's like 30. Droppers exist solely to load third party programs on compromised systems.

Containers got popular at at time when there were an increasingly number of people that were finding it hard to install software on their system locally - especially if you were, for instance, having to juggle multiple versions of ruby or multiple versions of python and those linked to various major versions of c libraries.

Unfortunately containers have always had an absolutely horrendous security story and they degrade performance by quite a lot.

The hypervisor is not going away anytime soon - it is what the entire public cloud is built on.

While you are correct that containers do add more layers - unikernels go the opposite direction and actively remove those layers. Also, imo the "attack surface" is by far the smallest security benefit - other architectural concepts such as the complete lack of an interactive userland is far more beneficial when you consider what an attacker actually wants to do after landing on your box. (eg: run their software)

When you deploy to AWS you have two layers of linux - one that AWS runs and one that you run - but you don't really need that second layer and you can have much faster/safer software without it.

a) containers don't contain

b) if you want to limit your hosting environment to only the language/program you expect to run you should provision with unikernels which enforce it

It's confusing but CVE-2025-55184 was released today (not the ones last week). CVE-2025-67779 is an update to that one.