Unikernels: Rise of the Virtual Library Operating System • Hacker News Board

Re: Unikernels: Rise of the Virtual Library Operating System

#21

Post by stormbrew » Tue, Jan 14, 2014, 11:02 PM UTC

cwzwarich wrote: post #15

stormbrew wrote: post #10

Earlier quoted context omitted.

As mentioned in a sibling you still have the hypercalls, and you definitely need those to still be present if you're running at ring 0 since, essentially, direct access to the hardware is probably an opportunity to attack the whole physical system (since hardware often has arbitrary bus access). Never mind the need to arbitrate access between multiple VMs. And this is what I mean when I say that taken to its conclusi…

You can use I/O virtualization to allow direct hardware access in a safe fashion, assuming that your CPU and peripherals support it.

This isn't the attack I'm referring to. The peripherals themselves have, potentially at least, complete access to the bus through DMA, so being able to convince them to, say, write to an inappropriate physical address (say the hypervisor's kernel), could lead to a significant breach of the security model. As far as I know, no processor-level features actually protect against this.

Re: Unikernels: Rise of the Virtual Library Operating System

#22

Post by stormbrew » Tue, Jan 14, 2014, 11:03 PM UTC

hcarvalhoalves wrote: post #12

stormbrew wrote: post #4

Earlier quoted context omitted.

I think the real problem with this sort of idea is that, in the end, you're just reinventing processes. There's already a way to write an isolated single purpose application and run it on a server: fork() and then exec(). If you want to bring the isolation level of that process down to just absolutely what it needs to run we've got things like jails and cgroups. You could probably run a Go app with no access to the f…

> Reproducibility and uniformity of environment (...) Shouldn't the unikernel approach actually improve reproducibility greatly? You build your application and all it's dependencies together, that should run exactly the same locally or on your Xen cloud.

They're not on the same scale. It does improve both, but it improves isolation to a much much larger degree. It also makes the world inside significantly different from the world outside, so it takes a different knowledge base to be able to program effectively. Particularly if the inside is an OCaml program, tbh.

Re: Unikernels: Rise of the Virtual Library Operating System

#23

Post by erichocean » Wed, Jan 15, 2014, 2:49 AM UTC

foobarian wrote: post #14

erichocean wrote: post #9

Earlier quoted context omitted.

Is there that much to be gained in avoiding kernel/user-space transitions? Yes, there's at least an order-of-magnitude improvement in packet processing, for example, if you bypass the kernel. Our mobile app runs WebSocket-like connections over UDP with libsodium for crypto, and we're moving our stack off of Node.js for exactly that reason.

I don't get this. Maybe you can win big if you start with an inefficient system but a run of the mill Linux box has been able to saturate gigabit links without breaking a sweat for a decade if not more. Things like file descriptor limits or numbers of connections are more of a pain in modern times, not necessarily a context-switch caused problem.

Linux (and Unix in general) is "control plane" software. It was literally developed to replace the people that used to patch phone calls using physical cables.

That thing they were patching? That's the "data plane". It was incredibly high bandwidth relative to the control plane, since it was completely optimized for moving data.

Back to Unix. Unix is designed for the control plane. It is not designed for rapidly moving large amounts of data with maximum efficiency. Why do we use it today for what are arguably "data plane" tasks? Well, when all you have is a hammer...

Nowadays, you can have both on the same machine: run Linux on the first core or two, and reserve the remaining cores for your app. Along with huge page allocations to reduce TLB impact, you can literally own all CPU activity on those cores, and lock all of your RAM too.

That app is a normal Linux app, but it runs on the raw hardware—like not having an operating system at all. When you also give your app complete control over the network hardware, you've completely bypassed the kernel.

With UDP, you don't even need a networking stack, making this approach particularly attractive. Another poster mentioned saturating a 10Gb link. How about saturating four 10Gb links on a single machine? It can be done with the E5 processors and the software architecture I described above.

We're shooting for 10 million packets processed per second on a single, ~$20K machine. That's pretty sweet if you ask me, and a hell of a lot more than Node.js can do.