eyberg

This is kind of a stupid "benchmark" but if we're going to walk down this road:

linux: elapsed: 0.019895s

nanos (running on said linux): elapsed: 0.000886s

Packages exist: https://repo.ops.city

Mounts also exist - in fact you can hotplug volumes on the fly on all the major clouds. People really like this cause they can do things like rotate ssl certs every few hours.

The file system exists - at the very least you need to load a program that sits on the filesystem but people are running webservers that write to temp files and load static assets and also databases.

I'm not sure what your comment means? What infrastructure? I just broke apart each of those into examples of how people use them today.

Access Control: There is none internally. We don't have the notion of users.

Logging: Keep using whatever you want be it elasticsearch, syslog, cloudwatch, etc. No opinions here.

Debugging: GDB works fine and in many cases since you can simply export the vm in it's entirety and then attach to it locally this becomes even easier to debug than the same application running on linux.

Profiling: We support things like ftrace and of course things like prometheus you can export.

Monitoring: Kinda in the same boat as logging - keep using whatever you are using today - datadog, victoria metrics, etc.

Throttling: This is traditionally an app-level concern that someone would implement at perhaps a load balancing layer - keep using whatever you are using.

Backup/Recovery: Running unikernels make it trivial to backup as you can clone running vms. In fact most cloud deploys involve making a snapshot that is already stored as a 'backup' and makes things like rollback much easier to do.

You can also run the full JVM and in fact I'd imagine that's how most of our JVM users actually use it today.

Sorry - just now seeing this. This is a build of PVM that works with Nanos. We're also maintaining that patch set as I don't ever see it getting included into the kernel (not anytime soon anyways).

It doesn't necessarily mean that but yes you most definitely can run native images - another example showing that: https://github.com/nanovms/ops-examples/tree/master/java/07-... . Both of these pair very well with unikernels. Especially quarkus has excellent boot time and low mem usage.

The rabbit hole goes even deeper. Georgios was thinking about this with Jikes even earlier: https://gousios.org/pub/gousios-mscthesis.pdf

microvms as espoused by things like firecracker offer full machines but have tradeoffs like no gpu (which makes it boot faster)

hyperlight shaves way more off - (eg: no access to various devices that you'd find via qemu or firecracker) it does make use of virtualization but it doesn't try to have a full blown machine so it's better for things like embedding simple functions - I actually think it's an interesting concept but it is very different than what firecracker is doing

No it wasn't - you can still easily replicate. I just did.

My point is that you shouldn't go around talking about how "secure" you are when you have large gaping things like this. This btw is not the only major security issue they have.

These people definitely do not understand security at all:

https://github.com/unikraft/unikraft/issues/414

Also - one needs to be careful cause many of the workloads they advertise on their site do not actually run under their kernel - it runs under linux which breaks a completely different type of trust barrier.

As for trust/full disclosure - I'm with nanovms.com

CGI has a very long history of security issues stemming primarily from input validation or the lack thereof.

Outside of nostalgia there's no engineering reason to do this - definitely not for performance.

That same go program can easily go over 10k reqs/sec without having to spawn a process for each incoming request.

CGI is insanely slow and insanely insecure.

> should be foolproof by design.

I think this is a core reason why containers have such a horrible security track record.

They weren't made by design.

One of the large problems is that there is no "create_container(2)". There are 8? different namespaces in conjunction with cgroups that make up "containers" and they are infinitely configurable. This is problematic and a core reason why we see container escapes almost every other month. Just look at user namespaces - some people use them and some people don't, but it was just a few months ago when multiple bypasses were published for them.

(I'm w/NanoVMs).

Firecracker is a complementary technology and not competitive.

Our main software - https://nanos.org is a linux kernel guest replacement whereas firecracker is a VMM (host) replacement for something like qemu.

So the vast majority of our users deploy to AWS, GCP, etc. and those deploys are created as ec2 instances (but without linux). Some of our users/customers use firecracker for ephemeral workloads.

bubblewrap is actually worse - there are known escapes in there that haven't been fixed for years

I kinda see the different side of the coin.

"a determined and amoral adversary" - I'd kinda disagree with this (the amoral adversary part being necessary). If you crawl through the vast data breach notification lists that many states are starting to keep - MA, ME, etc. there are so many of them (like literally daily banks, hospitals, etc. are having to report "data breaches" that never ever make the news) - not all of them are happening cause of ransomware. Sometimes it's just someone accidentally not locking a bucket down or not putting proper authorization on a path that should have it. It gets found/fixed but they still have to notify the state. However, if someone doesn't know what they are looking at, or it's a program so it really has no clue what it's looking at and just sees a bunch of data - there's no malicious intent but that doesn't mean that bad things can't happen because that data has now leaked out.

Guess what a lot of these LLMs are training on?

So while Andrey's software is finding all sorts of interesting stuff there's a bunch of crap being generated inadvertently that is just bad.

A better title might be "Kees Cook's account disabled for suspected malicious activity". He isn't exactly a random contributor.

Cloud vms are a main target for unikernels, however, as Russ mentions in one of the linked issues there actually is quite a lot of other code you need to include in your system depending on what you are deploying to.

For instance systems with arm64 might need UEFI or if you enable SEV now you need additional support for that which is why I'd agree with Russ's stance on this.

Every time someone asks us to provide support for a new cloud instance type (like a graviton 4 or azure's arm) we have to go in and sometimes provide a ton of new code to get it working.

Except in this case they are just running a linux payload - that which pretty much any firecracker provider could do.

No. As I'm responding to this Qualys just announced three new bypasses as of today: https://seclists.org/oss-sec/2025/q1/253 .

When we speak of 'hard security boundaries' most people, in this space, are comparing to existing hardware backed isolation such as virtual machines. There are many container escapes each year because the chunk of api that they are required to cover is so large but more importantly it doesn't have isolation at the cpu level (eg: intel vt-x such as VMREAD, VMWRITE, VMLAUNCH, VMXOFF, VMXON).

This is what the entire public cloud is built on. You don't really read articles that often where someone is talking about breaking vm isolation on AWS and spying on the other tenants on the server.

We definitely took inspiration and implemented in the nanos unikernel cause we think it's a great idea:

https://nanovms.com/dev/tutorials/applying-sandbox-security-...

Absolutely. Everyone who deploys unikernels to the public clouds does this. Some are better fits than others. AWS for instance you can build an image and deploy an ec2 instance in a matter of seconds.

Anything new is going to have people poking and prodding at it. It doesn't mean that the concept is 'bad'.

Linux has desperately needed an interface like io_uring for decades. Async IO was in Windows NT 3.1 in 1993.

> flatpak: I really like software distribution done with flatpak, packages are all running in their own namespace, they can't access all the file system, you can roll back to a previous version, and do some interesting stuff

As of today flatpak still has holes you can drive a truck through.

Firecracker boots up a runtime that has a full blown operating system in it - lambda just happens to call a known program with a known function. In that sense sure it provides similar functionality but it's really quite different. That's not what fly uses firecracker for, for instance.

Qemu/firecracker are in the same space - this is different.

These are most definitely in a different boat as you embed the guest functions inside the host program and then you register those functions. Taken from the readme:

> The host can call functions implemented and exposed by the guest (known as guest functions).

> Once running, the guest can call functions implemented and exposed by the host (known as host functions).

This is more in the 'safe plugin' type of space. As with most things in this space - the best way to learn about them is to simply try it out.

Firecracker can run ordinary linux/GPOS vms and unikernels.

Unikernels can run inside of firecracker.

Unikernels are focused on single applications whereas general purpose operating systems are focused on multiple applications.

This is focused on running functions embedded inside a host program. So it is fairly different than other things out there and in a class of its own.

The major tradeoff with firecracker is a reduction in runtime performance for a quick boot time (if you actually need that - this obviously doesn't work if your app takes seconds to boot). There are quite a lot of other tradeoffs too like 'no gpu' because that needs some of the support that they remove to make things boot fast. That's why projects like 'cloud hypervisor' exist.