Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Gone Full Unikernel

deferpanic.com

Post reply on HN
Print view View original

51–60 of 98 posts

Re: Gone Full Unikernel

#51

Post by ryao »

haberman wrote: post #11

Tell me if I'm missing something, but the premise of Unikernels seems to be that a ring-0 x86 hardware environment is the perfect fit for a universal container/host interface. Or to put it more charitably, since cloud compute services are based around booting VM images based on this model, we'll just go with it instead of trying to use an abstraction that is actually designed for this. Correct me if I'm wrong, but it…

> Tell me if I'm missing something, but the premise of Unikernels seems to be that a ring-0 x86 hardware environment is the perfect fit for a universal container/host interface. > Or to put it more charitably, since cloud compute services are based around booting VM images based on this model, we'll just go with it instead of trying to use an abstraction that is actually designed for this.

That is my understanding of part of the premise of unikernels. Another is security from having less code, although nothing stops you from having less code with Linux. LEDE/OpenWRT are Linux distributions that are often smaller than the sizes that are advertised for unikernels.

I consider containers using syscalls on a kernel that operates on bare metal to be a better abstraction.

> Correct me if I'm wrong, but it seems to me that the first thing any unikernel is going to do when it boots is switch the (virtualized) CPU out of x86 Real Mode (which all x86 machines boot into for legacy reasons, but virtually no one has needed since circa 1995) into protected mode.

That is only on x86/amd64 systems. It is different on other architectures.

> Is it just me or does this seem a little bit crazy?

The more I learn about unikernels, the more skeptical I become of them.

Re: Gone Full Unikernel

#52

Post by lifty »

ryao wrote: post #49
lifty wrote: post #42

Earlier quoted context omitted.

Hypervisors offer decent security and performance guarantees, which means they are good for sharing resources among potentially hostile customers. Their simple resource semantics and small ABI makes for a fairly secure abstraction.

Kernels do as well. Both have had security exploits that lead to privilege escalation. As containerization matures, I expect the security of a container host to become similar to that of a hypervisor. They are essentially doing the same thing. The only place on which they differ is the kind of abstraction that they use. LPARs/LDOMs are a much more secure abstraction for "sharing resources among potentially hostile cu…

I don't think kernels are inherently less secure than hypervisors, but as they stand, current hypervisor implementations have a better security track record than kernels. The basic point that I am trying to make is that both hypervisors and kernels are just pieces of software meant for partitioning and sharing hardware. Software that has simpler and smaller interfaces also has a lower probability of having bugs that lead to vulnerabilities. I agree that that there are better hardware partitioning implementations out there but unfortunately they are not so popular. I am looking forward to having formally verified kernels like seL4 become more popular.

Re: Gone Full Unikernel

#53

Post by brendangregg »

ryao wrote: post #46
brendangregg wrote: post #40

Earlier quoted context omitted.

Price/performance always wins. Can an application unikernel on a hypervisor (which is really a lightweight OS that nowadays supports many pass-through features) beat performance of an application on a regular OS? (I didn't mention containers, since they should ultimately be irrelevant to hot path performance). So can it? With a lot of work, I bet they can. So who has has the better price/performance? That's going to…

I suspect that the performance of a unikernel on a hypervisor vs an application on a POSIX system is somewhat analogous to the performance of hardware RAID vs ZFS. The performance of the abstraction used in the former is inherently worse than the performance of the abstraction used in the latter. The example of memory partitioning gives the latter a price/performance advantage and it is not the only one. I would be h…

Strawman. Lets talk about Xen and Unikernels. So you said:

> You stand to eliminate much more overhead from eliminating the hypervisor than you stand from eliminating the syscalls.

So my hypervisor application talks directly to devices, thanks to pass-through. What's that about syscalls again?

Re: Gone Full Unikernel

#54

Post by nostrademons »

niftich wrote: post #36
nostrademons wrote: post #22

Earlier quoted context omitted.

The premise of unikernels is that: 1. The job of an OS is to ensure that multiple programs can run on a single box without interfering with each other. 2. The job of a hypervisor is to ensure that multiple OSes can run on a physical box without interfering with each other. 3. In many cloud deployments, a single VM instance only runs a single user-defined program, which is programmed to a higher-level runtime than the…

I tried to read up on this, but I'm not too familiar with the terminology. Are unikernels the formal name for the idea of running your application 'bare metal'? In the parent post, does AMI mean Amazon Machine Image, or some Application M____ Interface?

Yeah, "running your application bare metal" is a useful first approximation. Technically, they consist of the toolchain and libraries necessary to replace OS functionality with userspace library calls, which then run on the bare metal. (Or technically, in any practical deployment they would run on a hypervisor, which presents an interface that looks like bare metal.) MirageOS, one of the first unikernel designs, works by statically analyzing an Ocaml program to identify OS calls and then only linking in the libraries required to support those particular calls, all of which have been re-implemented from the ground up for security.

Right now, much of the research on unikernels focuses on implementing a POSIX API. In other words, it replaces libc so that instead of eg. write() making a syscall into a kernel, write() inlines the code that the kernel would've run and talks directly to the hardware.

IMHO, the real wins for unikernels come when they start implementing higher-level interfaces, eg. Node or Rails or Django or HTTP or SQL or the JVM. Many programs are already written to these frameworks, with no knowledge of (or in some cases, access to) the underlying POSIX APIs, and the frameworks themselves often re-implement a large portion of the OS to create better domain-specific abstractions. Node or Python's asyncio, for example, implement their own schedulers that each run inside a single OS thread. Databases work in terms of pages, built on top of a filesystem; they effectively try to recreate the abstraction of a block device on top of a stream on top of a real block device. Websites often have large quantities of text that are sent back with every request (think of page layout in a templating engine, or JS bundles for a SPA). This data is usually copied and concatenated multiple times within a framework, while a bare-metal-aware web framework would store it in a buffer somewhere and write it out directly to the network card.

And yes, I meant Amazon Machine Image. Doesn't have to be Amazon, but I'm focused on the pragmatics of how you might deploy a real unikernel to solve problems, and wanted to make the point that you're going to be loading it into Xen or some other cloud hypervisor at the end.

Re: Gone Full Unikernel

#55

Post by derefr »

rjsw wrote: post #27
brendangregg wrote: post #23

Earlier quoted context omitted.

I wouldn't say that unikernels were entirely undebuggable. I spent a few hours hacking and came up with a proof of concept dom0 profiler, and learned some debugging benefits: one symbol table for the entire binary, one place to turn on frame pointers for everything, etc. http://www.brendangregg.com/blog/2016-01-27/unikernel-profil...

There is nothing stopping people from creating a unikernel for a dynamic language that also includes the development tools. A Lisp Machine on Xen would be one model.

Erlang on Xen is already that way. You can use the full Erlang profiling/tracing/debugging/observing toolkit on an EoX node.

Re: Gone Full Unikernel

#56

Post by ryao »

brendangregg wrote: post #53
ryao wrote: post #46

Earlier quoted context omitted.

I suspect that the performance of a unikernel on a hypervisor vs an application on a POSIX system is somewhat analogous to the performance of hardware RAID vs ZFS. The performance of the abstraction used in the former is inherently worse than the performance of the abstraction used in the latter. The example of memory partitioning gives the latter a price/performance advantage and it is not the only one. I would be h…

Strawman. Lets talk about Xen and Unikernels. So you said: > You stand to eliminate much more overhead from eliminating the hypervisor than you stand from eliminating the syscalls. So my hypervisor application talks directly to devices, thanks to pass-through. What's that about syscalls again?

It is not just syscalls. You either have inefficiency from double caching or inefficiency from a lack of a global page replacement algorithm. You also have internal fragmentation from memory partitioning, which prevents you from running as many applications and/or reduces memory available for cache. I consider these to be fundamental disadvantages.

Re: Gone Full Unikernel

#57

Post by superuser2 »

coroutines wrote: post #21
thekemkid wrote: post #7

The good news is, for the average user, unikernels are pretty much guaranteed to be mainstream and streamlined at some stage in the future, thanks to Docker acquiring Unikernel Systems, and the awesome work that the like of deferpanic are doing. :D [1]: https://blog.docker.com/2016/01/unikernel/ [2]: http://www.linuxjournal.com/content/unikernels-docker-and-wh...

I'm with you - Docker has done an excellent job of showing application developers the minimum they need for a runtime. Side-thought: Can Android be dockerized?

> Can Android be dockerized?

Why? Aren't Android apps already sufficiently sandboxed?

Re: Gone Full Unikernel

#58

Post by viraptor »

kev009 wrote: post #20

I can't help but think this is just a severe reaction to the tire fire that most Linux distros are, especially RedHat/CentOS and Ubuntu. BSD or Alpine Linux get in the way a lot less, are much more customization and compact, and have a smaller attack surface while still catering to production operations where you can run shells, profiling, logging, etc inside the execution environment.

I'd rather say it's a response to technical advancements in virtualisation. You want an app that can talk to other things, but is otherwise completely isolated as far as crashes and exploitation goes. We wanted that before protected memory was a thing. We wanted that when networks happened. We wanted that when selinux was created. etc. etc.

This is just the next step. I've got an app which needs communication channels and possibly persistent storage - isolate everything else. This is what unikernels provide. If it gets rid of some of the redundant system parts is just a cherry on top.

Re: Gone Full Unikernel

#59

Post by viraptor »

deferpanic wrote: post #5
edwintorok wrote: post #4

What languages do you support for unikernel? Is it just Go, or do you plan to support others in the future (e.g. OCaml for MirageOS)

So this is kind of a two part question: 1) What languages right now - Go, php, javascript, ruby through the rumpkernel project - rumpkernel.org. 2) We are implementing support to support user supplied images which will let you run mostly anything in the very near future. We plan to be completely agnostic.

Not from deferpanic, but there's also rumprun for rust: https://gandro.github.io/2015/09/27/rust-on-rumprun/ (it's even easier these days - integrated into cargo target)

Re: Gone Full Unikernel

#60

Post by jsolson »

bogomipz wrote: post #14

Can someone explain why these rump kernels can not be run on AWS if deferpanic has Xen as a target? AWS is Xen-based. I understand that there currently isn't a target for Docker so that takes Google Cloud out of the equation. The following two statement seem to be contradictory: Can I use Google Cloud or AWS? You could - although you won’t write much more than a toy app - not until things are changed. DeferPanic offe…

> I understand that there currently isn't a target for Docker so that takes Google Cloud out of the equation.

Google Compute Engine runs a lot more than just Docker images. It allows you to run arbitrary x86 VMs, just like EC2. It is not based on Xen, however (it is a combination of KVM and a non-QEMU VMM about which I wish I could say a whole lot more, but I don't think we're prepared to do that just now).

Post reply on HN