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

71–80 of 98 posts

Re: Gone Full Unikernel

#71

Post by ryao »

e12e wrote: post #66
ryao wrote: post #6

> Try 5, 10, 20 megabyte small. OpenWRT/LEDE will happily work on a system with 4MB of storage: https://www.lede-project.org QNX had a graphical environment, a web browser, a web server, a text editor, image viewer, various games, a package manager, etcetera on a 1.44MB floppy: http://m.youtube.com/watch?v=K_VlI6IBEJ0 Less is definitely more, but you do not need a Unikernel to achieve such sizes and you lose observab…

>> Try 5, 10, 20 megabyte small. > OpenWRT/LEDE will happily work on a system with 4MB of storage: > https://www.lede-project.org > QNX had a graphical environment, a web browser, a web server, a text editor, image viewer, various games, a package manager, etcetera on a 1.44MB floppy This is all true, but you skipped the sentence following the one you quoted: "Depending on your needs, you can go down into the kilobyt…

A microkernel could go into the kilobyte range too. seL4 is definitely in that range. The smallest Linux kernel bzImage that I ever compiled was something like 570KB, so embedded Linux might be able to reach that range too. That would of course include an application. The QNX demo likely could reach such sizes too if most of the things in it were removed. For those that are unaware, QNX is a microkernel based system.

Re: Gone Full Unikernel

#72

Post by la6470 »

While AWS lambda actually run on containers they could as well in future run on unikernels and give the same benifits of reduced attack surface and low maintenance of server infeastructure.

Re: Gone Full Unikernel

#74

Post by eru »

ryao wrote: post #69
brendangregg wrote: post #65

Earlier quoted context omitted.

> You either have inefficiency from double caching No double caching: most of our applications have an in-memory working set, and no disk state. Some do (eg, Cassandra databases). > from a lack of a global page replacement algorithm Oh, so it's more efficient to be running where paging (aka swapping) is allowed? Sure, for memory footprint, but for runtime performance you're banking on it reaching a state where paging…

> No double caching: most of our applications have an in-memory working set, and no disk state. Some do (eg, Cassandra databases). I see no disadvantage for unikernel on hypervisor setups versus applications on a container host setups in applications where there is no disk state. However, I see no advantage either. The techniques used to talk to hardware directly work in userland too. netmap is a fantastic example of…

> However, the world is adopting containers in traditional kernels and unless a unikernel on a hypervisor can be better, I do not see much value in devoting resources to unikernels too.

Unikernels allow more experimentation. The interface that the hypervizor provides is generally lower level (especially with hardware passthrough) than the traditional operating system's interface.

Unikernel 'programs' would normally use a library as an abstraction layer to bridge the gap. These libraries are easier to swap and change and experiment with than traditional OSs. (At least that was the whole justification for exokernels in the 90s, the approach our current hypervisors grew out of.)

Re: Gone Full Unikernel

#75

Post by eru »

lifty wrote: post #52
ryao wrote: post #49

Earlier quoted context omitted.

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…

Kernels usually provide quite a lot of abstraction in addition to secure partitioning and sharing. And that's arguably wrong: providing abstractions is complicated (thus inherently less secure), and one size does not fit all.

In a unikernel setup abstractions can live much more comfortably in libraries.

Re: Gone Full Unikernel

#76

Post by eru »

viraptor wrote: post #70
XorNot wrote: post #68

Earlier quoted context omitted.

The problem is you reinvent kernels when doing this before too long. Containerization is a reaction to virtualization being too expensive - and unikernels are still pulling in huge amounts of redundant code and runtime compared to containers where the kernel af least is shared.

I'm not sure that's a bad thing. If you're running only one app, there's a lot of things you don't need. No process groups, no scheduling hierarchies, no user privilege checks, likely no filesystem caching (maybe even no filesystem?), no legacy device handling, no terminals. We're kind of going towards replacing the big kernel with a posix-to-virtio layer already, and it may not be a terrible idea.

Same arguments as those in favour of exokernels in the 90s.

Re: Gone Full Unikernel

#77

Post by eru »

ryao wrote: post #71
e12e wrote: post #66

Earlier quoted context omitted.

>> Try 5, 10, 20 megabyte small. > OpenWRT/LEDE will happily work on a system with 4MB of storage: > https://www.lede-project.org > QNX had a graphical environment, a web browser, a web server, a text editor, image viewer, various games, a package manager, etcetera on a 1.44MB floppy This is all true, but you skipped the sentence following the one you quoted: "Depending on your needs, you can go down into the kilobyt…

A microkernel could go into the kilobyte range too. seL4 is definitely in that range. The smallest Linux kernel bzImage that I ever compiled was something like 570KB, so embedded Linux might be able to reach that range too. That would of course include an application. The QNX demo likely could reach such sizes too if most of the things in it were removed. For those that are unaware, QNX is a microkernel based system.

seL4 doesn't provide very much to the programs, does it? I think it closer in spirit to Xen than to the linux kernel?

Re: Gone Full Unikernel

#78

Post by eru »

nostrademons wrote: post #54
niftich wrote: post #36

Earlier quoted context omitted.

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, work…

Some (relational) databases go to great lengths to recreate on top of a file system an interface that looks more like the block level storage that's underlying.

A unikernel can cut out the middle man here.

Re: Gone Full Unikernel

#79

Post by johncolanduoni »

superuser2 wrote: post #57
coroutines wrote: post #21

Earlier quoted context omitted.

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?

They're pretty sandboxed, but every Android app gets a JVM, no exceptions allowed (even Android's pure C++ API is just a wrapper around JNI calls). And in the case of the old Dalvik VM, it's a terrible JVM.

Re: Gone Full Unikernel

#80

Post by reiger »

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…

IBM terminology might be confusing me - but looking at published security targets it appears LPAR's themselves have only ever been evaluated at EAL4 with flaw remediation (ALC 2) and PR/SM being evaluated at EAL 5 but neither to any specific protection profile. This means that IBM created their own evaluations and gave themselves a "certification".

Protection profile less CC evaluations are worthless in the eyes of most governments and CC schemes, but kudos to IBM product management and marketing for creating competitive FUD.

As of a year ago LDOM's (Oracle VM for SPARC) hasn't had a CC evaluation and I'm not seeing anything currently in evaluation. Solaris Zones have been evaluated under the Solaris OSPP EAL4 + extensions evaluation.

The biggest reason that virtualization technologies haven't had a CC evaluation with a protection profile is that no US NIAP approved protection profile existed and the draft ones that were circulated were crap.

Assurance levels (EAL) are deprecated for newest NIAP protection profiles as the higher assurance levels (EAL4) were cost and time prohibited for vendors to complete before the product was outdated. Many people wrongly think common criteria is a security evaluation (free of bugs) - it's not - it's a security architecture evaluation (is the documented behavior working correctly).

There is a schism in CC - everything is changing - anything we know today is wrong and will change.

TL;DR: Common Criteria is a joke and doesn't actual mean what you think it does.

Post reply on HN