Comment by mato | Hacker News Reader

Comment by mato | Hacker News Reader

Parent Full thread

Co-author of the paper referenced in the blog post here.

1. Regarding bugs: There is a lot of code in your monolithic OS kernel. There have been, and will be, a lot of vulnerabilities in that code. Various sandboxing mechanisms notwithstanding, the vast majority of processes running on your system can potentially use all of that code as an attack vector. Unikernels let you switch off access to most of that "host" code, and, through the use of a library OS, contain only the minimal set of libraries needed to run your application in the "guest". Regarding updates: Valid point, but no different from any modern application of substantial complexity, except that now you also have to update (e.g.) the library providing its TCP stack.

2. Unikernels don't make that problem any worse. In fact, if you run on something like Muen (https://muen.sk/), it'll mitigate a bunch of these attacks by giving you a less precise RDTSC at the subject ("VM") level.

3. I don't follow. Implement what?

If the unikernel is running as a normal process, all that potentially vulnerable code is still on the box, and still potentially executable in the event of a vulnerability. The security selling point of a standard unikernel is that the all the potentially-vulnerable code doesn't even exist, because only the libraries that are actually used get compiled and linked into the app, and it has no code relevant to functionality that it's not actually using.

The paper suggests using system-call filtering via seccomp or similar to block off this attack surface, but if you trust seccomp to have zero bugs, you might as well do traditional process sandboxing a la Google Chrome.

The problem unikernels solve is that traditionally, a vulnerability in C code means "game over" and the box is completely pwned with all memory and storage directly accessible, while with a unikernel, a vulnerability means only that an attacker can access other functionality within the app, and can't rely on eg. a shell or a debugger being available to arbitrarily move bytes around.

> If the unikernel is running as a normal process, all that potentially vulnerable code is still on the box [...]

Correct. Conceptually the same applies to all Type 2 hypervisors. Type 1 less so, but you could still potentially exploit Xen and you have all of the dom0 to play around in.

> The paper suggests using system-call filtering via seccomp or similar to block off this attack surface, but if you trust seccomp to have zero bugs, you might as well do traditional process sandboxing a la Google Chrome.

If you do that, you will have to do a line-by-line analysis of the code you want to sandbox in order to determine exactly which syscalls it's using. With the approach presented in our paper the developer does not need to care about this. For example, she can develop her MirageOS unikernel as a normal UNIX process and switch to a guaranteed-to-work-minimal-seccomp sandbox with a simple change of target (build-time configuration option).

But yes, you are now trusting seccomp instead of KVM. I believe in giving people the ability to easily make that choice.

> The problem unikernels solve is that traditionally [...] can't rely on eg. a shell or a debugger being available to arbitrarily move bytes around.

That part does not change with the sandboxing mechanism changing. The stuff that's inside is still only your unikernel.

> you are now trusting seccomp instead of KVM.

Which do you trust more?

That's a very good question. The answer is, "it depends".

For the 80% case, on x86_64, I consider them more or less equivalent. KVM is used daily in anger to provide isolation (e.g. GCE, and now ChromeOS) and has been around much longer but you need to trust hardware virtualization which is a large attack surface on the CPU itself. Given what we've learned about CPU vulnerabilities over the last year, I wouldn't be surprised to find some lurking in the VT-x/SVM implementations.

Seccomp OTOH is difficult to use correctly for arbitrary/existing applications but exposes less of the kernel (depending on your metric, see our paper) and does not need hardware virtualization.

For the 20% case, where the stakes are higher (e.g. High Assurance), I would use something like Muen or SeL4 and run a disaggregated system on top of that.

I feel like (1) might be easier to explain as akin to the JS bundling+tree-shaking process.

I'm aware it's not an entirely accurate metaphor, but it might turn out to be a more accessible one for opening a conversation.

>There is a lot of code in your monolithic OS kernel.

This code is usually there for a reason and a unikernel will have to implement large swaths of this code anyway.

Networking isn't trivial and I don't think anyone will be reimplementing the TCP/IP, UDP/IP, ARP, DHCP and more stacks without breaking in a few bugs themselves.

Example, modern TCP congestion control requires a very precise packet pacing and timing.

Another example, TCP retransmission will be required at some point, the code doing this will have to run side-by-side with the app. This will also be some amount of code.

And all this just piles up and up.

The only real advantage I see for unikernels is that because all the hard work is done by the hypervisor they don't have to bother implementing device drivers and task scheduling but end up either replicating or using the hypervisor's own networking stack and a bunch of other subsystems.

> This code is usually there for a reason and a unikernel will have to implement large swaths of this code anyway.

The largest part of a monolithic kernel today is devices drivers, by far.

> Networking isn't trivial and I don't think anyone will be reimplementing the TCP/IP, UDP/IP, ARP, DHCP and more stacks without breaking in a few bugs themselves.

Sure. And then more people will use those stacks, and they will get better. The more the merrier, we have too much of a software monoculture anyway.

> The only real advantage I see for unikernels is that because all the hard work is done by the hypervisor they don't have to bother implementing device drivers

This. People continually underestimate the amount of work required to support the hardware ecosystem. This is also why rump kernels (note, not the same term as the unikernel known as Rumprun) are such an achievement, also very much underappreciated.

Well, yes, a lot is device drivers, but not most. You can make the Linux kernel, for example, minus almost all drivers. That usually slims down the kernel image by a few megabytes. More when you drop various other drivers and subsystems you technically no longer need. Though on most modern systems almost 80% of the drivers are modules and won't be loaded if not needed. The diskspace they consume is irrelevant for most intents and purposes (below 100MB on my distro).

> The more the merrier, we have too much of a software monoculture anyway.

Linux and some other kernels allow userspace apps to have their own network stack in userspace, latest kernels allow even larger sections of the networking subsystems to be entirely in userspace.

I think this approach should be favored over a unikernel since it uses the natural x86 privilege seperation between userspace and kernel.

How does access control work? There are plenty of APIs that need to validate access (e.g. ping or raw IP sockets can require sudo). If it's all running in-process it seems like there's no security you can implement, or the security mechanism would end up being super-complex like inspecting the TCP packets (which may solve networking use-cases but doesn't do so well for all the APIs).

*EDIT: Unikernels are neat as replacements for VMs since the abstraction layer can be much less costly/higher performance. They cannot be used as regular applications running on the OS due to how security is implemented.

Reply on news.ycombinator.com