Hello HN! We've been working on a new hypervisor https://kwarantine.xyz that can run strongly isolated containers. This is still a WIP, but we wanted to give the community an idea about our approach, its benefits, and various use cases it unlocks. Today, VMs are used to host containers, and make up for the lack of strong security as well as kernel isolation in containers. This work adds this missing security piece in containers. We plan on launching a free private beta soon. Meanwhile, we'd deeply appreciate any feedback, and happy to answer any questions here or on our slack channel. Thanks!
Not interested in using it, but the licensing here is going to be the real killer blow here. Word to the wise: the market of people who want to use your tool and pay for it is smaller than you think. It's the same mindset that kills most of these projects, thinking that the "average users" are going to represent a considerable portion of your income. It won't. Focus on milking enterprise users who want to pay hand over fist for stuff like this, but don't keep it closed source and slap your "patent pending" line on top. You're selling zero-marginal-utility here, and it's not super hard to see.
There was a question (now deleted) on difference between this and Firecracker. FC/gVisor/Kata use VMs to sandbox containers. However, VMs incur high runtime overhead (not to be confused with fast booting) and need to be provisioned. We use hardware virtualization to directly run system/app containers -- no I/O emulation, no expensive VM exits, scale as needed.
I was the one who posted that question and I deleted it because I understood I was asking to compare apple to oranges. Firecracker uses KVM under the hood. With regards to the overhead, sure, there's going to be resources needed but firecracker is pretty good at running VMs will low level overhead. We're talking thousands on a single host.
I've done some fair share of evaluating firecracker for https://github.com/combust-labs/firebuild and the need to provision is red herring. firebuild can run a VM directly from a Dockerfile and Docker image. Fly.io team does something similar. It's basically a fully functional app out of the container within a matter of milliseconds.
What would be nice is to see a direct comparison between your solution and firecracker.
I hesitated to chime in with specifics because I haven't done any real work on timing and profiling and because my dev environment is a NUC which, while zippy, is not the state of the art execution environment for Firecracker.
But, long story short: I restart test Firecrackers constantly, from shell scripts, and from start to my Go application logging its first "I'm listening" message after its VM has fully initialized, it's essentially instantaneous.
I'm sure it could be made faster, but making it faster would in no meaningful way change my life.
Instances on Fly can take a second or two to come up, but that's orchestration overhead, not Firecracker (Fly is zippy, too, don't get me wrong.)
That’s definitely true for no orchestration. If the kernel and rootfs is at the jailer location, things are instant. You guys have your owninit system which makes things pretty fast, indeed. I rely on whatever init system is the default for a given os so that adds an overhead because it implies running the app as an upstart / systemd / whatever service.
I think people would take this more seriously and engage with it more deeply if you posted the technology white paper, rather than asking for people to sign up for it. There are I'm sure details I'm missing, but Firecracker startup (for instance) is very fast; so, for that matter, is vanilla gvisor.
Thanks! We will post detailed technical docs on design/features soon. FC improved kernel boot up time (by stripping unnecessary functionality). However, runtime performance takes a hit due to I/O virtualization/emulation: https://www.usenix.org/system/files/nsdi20-paper-agache.pdf
Have you measured the performance difference between your system and Firecracker? I'm interested in knowing more about how you're quantifying this. As I said, it'd be easier to engage with this if your technical overview was public.
It's also a little tricky to get my head around how you're simultaneously winning on I/O performance by not virtualizing it, and also shielding me from host kernel vulnerabilities. Some of that I/O overhead you're talking about is spent in the service of putting a security boundary between my guests and my host.
Yes, we will post the numbers soon. However, what I was alluding to in my last comment was that FC runtime performance is far from native (i.e., no VMs). Therefore, there's definitely room for improvement. Depending on the use case, that may or may not be meaningful.
I actually posted (and since then deleted) a question asking how does this differ from firecracker. I deleted the comment because this claims to be a hypervisor and firecracker depends on kvm so it's a different level playing field.
The site seems light on details. As a security guy, I'm particularly interested in (and a skeptic of) claims of "de-privileging" a Linux kernel. Firecracker[1] micro VMs are very fast, "feel" like containers, and don't depend on modifying the guest OS for security. Plus they're FOSS. This is what I'd measure Kwarantine against; you need to be in the ballpark on all these characteristics and knock it out of the park on manageability to interest me.
21 comments
[ 3.3 ms ] story [ 59.9 ms ] threadI don't think there's much of a market for a new closed-source, patent-encumbered hypervisor for Linux...
And, perhaps obviously, I personally would never use such a thing.
I've done some fair share of evaluating firecracker for https://github.com/combust-labs/firebuild and the need to provision is red herring. firebuild can run a VM directly from a Dockerfile and Docker image. Fly.io team does something similar. It's basically a fully functional app out of the container within a matter of milliseconds.
What would be nice is to see a direct comparison between your solution and firecracker.
I hesitated to chime in with specifics because I haven't done any real work on timing and profiling and because my dev environment is a NUC which, while zippy, is not the state of the art execution environment for Firecracker.
But, long story short: I restart test Firecrackers constantly, from shell scripts, and from start to my Go application logging its first "I'm listening" message after its VM has fully initialized, it's essentially instantaneous.
I'm sure it could be made faster, but making it faster would in no meaningful way change my life.
Instances on Fly can take a second or two to come up, but that's orchestration overhead, not Firecracker (Fly is zippy, too, don't get me wrong.)
Love your work by the way.
It's also a little tricky to get my head around how you're simultaneously winning on I/O performance by not virtualizing it, and also shielding me from host kernel vulnerabilities. Some of that I/O overhead you're talking about is spent in the service of putting a security boundary between my guests and my host.
[1] https://github.com/firecracker-microvm/firecracker