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

What is a 'unikernel'?

ma.ttias.be

Post reply on HN
Print view View original

31–40 of 71 posts

Re: What is a 'unikernel'?

#31

Post by derefr »

kozukumi wrote: post #2

Am I the only one getting a bit fatigued by all of this now? I think when we hit containers I just got a bit tired of going even further down the rabbit hole. Yes I might get a little more performance or stability or whatever from a container vs a full VM or a unikernel vs a container but it just gets more frustrating to manage in my experience. Anybody else feel the same? When I just had a full VM with a full stack…

Unikernels are about security by auditability, mostly. Where containers have all of the security problems of two layers of operating systems and a container daemon and a complete OS kernel (before you even get to a hypervisor), unikernels are just your app and the drivers it needs sitting on the hypervisor. Or even on bare metal.

It's a fairly different philosophy—I don't think anyone really cares about the performance aspect of it (those people care more about getting zero-copy low-level IO in userland while still reaping the "control-plane" benefits of having an OS, using e.g. Snabb Switch.)

It's more like the philosophy behind Erlang releases or black-box "appliance" VMs. Which is, basically, that you don't maintain "the OS" as a thing separate from your app; you just maintain "your app", and any bits of OS are basically part of the vendored deps of each successive app release.

Re: What is a 'unikernel'?

#32

Post by moby_click »

dschatz wrote: post #9

1) How does a unikernel differ from a library OS? Is a unikernel a kind of library OS? 2) Is the specialization the important aspect? I see OSv referred to as a unikernel but it does no specialization, it supports almost the entire Linux ABI. I'd argue it is a library OS, though.

1) According to the source article, a unikernel is a kind of library OS and I think you hit the right spot with

2) specialization. AFAIK the the concept of a library OS is from a time when single purpose computing was not on the agenda. We could argue a lot about the different ways of multiplexing and isolating different workloads and how maybe privilege levels were meant to solve the same problem as hardware virtualization but the spirit of unikernels (and library OSs) is to use language and program against an API that specializes to whatever ABI your target happens to be. The name unikernel is used more in the context of specialized applications in the sense of what a UNIX process is supposed to be (do one thing) but I'd say the important aspect is still the use of language technology which then enables specialized code.

I'm not too familiar with OSv but I think the goal is to provide a runtime for off the shelf java applications. It should be possible to fuse an application with just the needed parts of libc and drivers, though.

Re: What is a 'unikernel'?

#33

Post by querulous »

alextgordon wrote: post #24
mahyarm wrote: post #13

Earlier quoted context omitted.

Or if you want to remove a potential layer of security issues.

I am exceptionally sceptical that "specialised" and "secure" are anything but opposites. "One hundred novel implementations of /dev/random" is a security nightmare. What you want is one implementation of /dev/random that everybody uses. Like uh, Linux. Same goes for every other element of the kernel. A secure kernel does not come from using (I'm sorry to say) a hipster programming language, it comes from decades of a…

unikernels are only single language now for convenience and research purposes. in the future you'll probably compile to something similar to the llvm ir and generate a unikernel from that. there'll probably be a standard /dev/random, a standard tcp stack, a standard http parser, etc

Re: What is a 'unikernel'?

#34

Post by rodgerd »

erikpukinskis wrote: post #20
kozukumi wrote: post #2

Am I the only one getting a bit fatigued by all of this now? I think when we hit containers I just got a bit tired of going even further down the rabbit hole. Yes I might get a little more performance or stability or whatever from a container vs a full VM or a unikernel vs a container but it just gets more frustrating to manage in my experience. Anybody else feel the same? When I just had a full VM with a full stack…

There's a huge spike of value created when you cross the threshold of "you really don't need to think about sysadmin stuff, you can just focus on the application layer." Heroku was the first to cross it, and they do a bang-up job with Rails apps, but ever since it came out there has been this sort of question hanging in the air of "how does this generalize?" A VM on something like Amazon EC2 was the best we could do…

> There's a huge spike of value created when you cross the threshold of "you really don't need to think about sysadmin stuff, you can just focus on the application layer."

Right up until you discover that availability and data integrity and security are still problems, as you discover when it turns out your understanding of Amazon's AZs is faulty and your business goes offline.

Re: What is a 'unikernel'?

#36

Post by grogenaut »

asymmetric wrote: post #28

I don't understand the point of running a unikernel inside a Docker container. I mean, Docker runs on top of the Linux kernel, so how is this reducing the stack in any way?

in general you would run it inside of xen or other hypervisor. iirc in docker the one thing you CANT change is the kernel.

Re: What is a 'unikernel'?

#37

Post by kasey_junk »

alextgordon wrote: post #24
mahyarm wrote: post #13

Earlier quoted context omitted.

Or if you want to remove a potential layer of security issues.

I am exceptionally sceptical that "specialised" and "secure" are anything but opposites. "One hundred novel implementations of /dev/random" is a security nightmare. What you want is one implementation of /dev/random that everybody uses. Like uh, Linux. Same goes for every other element of the kernel. A secure kernel does not come from using (I'm sorry to say) a hipster programming language, it comes from decades of a…

The point of something like Halvm, the Haskell unikernel, is that can bring to bear a lot of formal methods for proving the components are secure. This sort of thing is untenable in a general purpose OS, but for specialized use case it makes a lot of sense.

Here (https://github.com/GaloisInc/haskell-tor) for instance is a Tor implementation written for HalVM. The surface area for proving this implementation is secure is dramatically smaller than the more general purpose one. That it is more efficient about resources means that you can run more nodes, which in this particular case is very important.

The author gave a talk at QCon last week, I can't seem to find video of it just now...

Re: What is a 'unikernel'?

#38

Post by grogenaut »

kasey_junk wrote: post #35

This article references a golang unikernel, but doesn't name it. Does anyone know what it is referencing?

http://lsub.org/export/clivesys.pdf clive is the golang one. It's not focused on actually running golang programs. It's acutally more of a research project by some academics who are looking into replacing unix style ipc with golang style channels (because they can return an error). I was unable to get any response from them depsite trying several different contacts. I also couldn't get their system to actually compile even though I tried several different targets.

Re: What is a 'unikernel'?

#39

Post by lobster_johnson »

alextgordon wrote: post #8
kozukumi wrote: post #2

Am I the only one getting a bit fatigued by all of this now? I think when we hit containers I just got a bit tired of going even further down the rabbit hole. Yes I might get a little more performance or stability or whatever from a container vs a full VM or a unikernel vs a container but it just gets more frustrating to manage in my experience. Anybody else feel the same? When I just had a full VM with a full stack…

I don't think containers are related to unikernels. The whole point of containers is to sacrifice a bit of performance in order to gain convenience. Whereas for unikernels, it's the opposite > Unikernels leverage the advantages of virtualisation to create an operating system that's as specialised and optimised as possible. It makes no sense to craft a hyper efficient kernel and then run Ruby on it. If your requiremen…

Containers don't sacrifice performance at all — that's a big part of why they are so popular. Containers are completely ordinary processes that happen to be namespaced and isolated through kernel mechanisms. They have direct access to hardware and all sorts of kernel services such as file systems and sockets. The only indirection involved is the overlay file system, but anything I/O-critical is usually mounted from the host. There's no runtime checking or proxying or anything, and therefore no runtime cost.

Re: What is a 'unikernel'?

#40

Post by nickpsecurity »

I keep meaning to write a counter to the linked paper by Anti on I/O and whatever else I spot once I get past that part. Paints an inaccurate history of I/O and where problems come in. The I/O actually started more complex and effective with dedicated I/O processors, architecture, & programs. This eventually became Channel I/O for mainframes:

https://en.wikipedia.org/wiki/I/O_channel

Thanks to that, the compute nodes are always computing and I/O processors are always handling the interrupts, protocol processing, whatever. This kept utilization and throughput high. Things being so expensive are why they stripped components out until the small machines DOS and UNIX were on didn't support crap, esp Channel I/O. Like most legacy effects, such fundamentally architecture was kept in there as hardware improved and got beyond cheap enough for a Channel I/O-like solution. We've seen over past decade various offloading mechanisms but the original architectures were fundamentally better for smart I/O and virtualization. They just weren't adopted, forcing people to work around the crap we have in clever ways.

Note 1: Even true for embedded as I/O coprocessors can greatly aid determinism and throughput. Upon my suggesting it, Ganssle sent me a SOC that had a mid-to-high end part for compute plus a weaker CPU for I/O handling with many supposed benefits. The old mainframes had a high-end processor for compute plus low-end one for I/O handling. Put a smile on my face to see the lesson rediscovered. :)

Note 2: A number of systems, esp kernelized architectures, tried to minimize the amount of OS for user applications or OS's starting with VM/370 I believe and KeyKOS later doing nanokernel. So, that isn't new either. Rump kernels easy integration with kernels without forks or extensive modifications are a significant innovation, though.

Post reply on HN