Agreed. The vast majority of prod workloads are persistent services that we want running 24/7.
865 karma · joined October 23, 2018
did someone say 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
Containers do not contain.
Trivial to spin up a prisma postgres instance and see everything from busybox to a full blown proc including very specific linux flags.
They should clarify which workloads are actually using their kernel vs linux. I suspect most are the latter.
If you don't even want to pay for that though scheduling unikernels on something like ec2 gets you your full vm, is cheaper, has more resources than lambda and doesn't have the various limitations such as no gpu or timeouts or anything like that.