
Unikernels, meet Docker - amirmc
http://unikernel.org/blog/2015/unikernels-meet-docker/
======
amirmc
We'll be releasing the code sometime tomorrow afternoon. We need a bit of
extra time to clear out the unused code, make a readme, and also get some
rest. :)

I'll add a link to the blog post when it's live.

~~~
ibotty
did you do that already?

~~~
amirmc
Not yet (sorry) but will do soon!

~~~
amirmc
Just to close the loop, we did release the code.

See the post at: [http://unikernel.org/blog/2015/contain-your-
unikernels/](http://unikernel.org/blog/2015/contain-your-unikernels/)

------
aabaker99
this reminds me of a recent presentation posted here about OpenBSD's coming
support for "pledges" [1].

I suppose the difference here is that pledges use a single kernel but restrict
kernel interfaces for each process while the unikernel approach creates a
kernel subset for each VM (and thus each process, for VMs dedicated to a
single process).

Can anyone knowledgeable comment about the advantages or disadvantages of
each? I'm guessing unikernals will be more portable (only OpenBSD is doing
pledges to my knowledge) and more popular with the containerization movement.
Can pledges accomplish the same objective with better use of system resources?

Edit: clarity about portability point

[1] [http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-
current/man2/...](http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-
current/man2/pledge.2)

~~~
masklinn
They're compatible approaches, you could use pledges in a unikernel for
exactly the same reason in order to _further_ reduce the application's attack
surface: a unikernel includes only what the application needs but it can't
take advantage of the application's needs varying (reducing) over time[0],
which is pledge(2) allows.

[0] one of the reasons for pledge(2) was the realisation/understanding that
many applications have an initial setup phase followed by a "stable state",
where the stable state needs significantly less services than the setup e.g.
setup might require reading config files but the steady state doesn't and just
listens on a socket, so you can call pledge(2) multiple times and further
reduce the application's abilities (attempting to increase them will fail with
EPERM)

~~~
cpuguy83
Neat!

------
legulere
What this is ignoring is that the hypervisor already is a full operating
system. If the linux people finally make isolation secure I see no future for
unikernels.

~~~
mtgx
A hypervisor has a much smaller attack target than a full blown OS. The kernel
alone of a mainstream OS can be an order of magnitude larger than a
hypervisor. Xen, for instance, has fewer than 150,000 lines of code. The Linux
kernel has about 15 million. A full Linux distro probably has around 200-300
million. So a full OS has about two orders of magnitude (100x) more potential
for exploits.

~~~
mwcampbell
Is there any Xen-based public cloud that's not running a full conventional OS
kernel (Linux or otherwise) in dom0? If not, then the theoretical smaller TCB
of Xen doesn't matter in practice. And of course, some major public clouds use
KVM, so they're effectively using a full Linux kernel as the hypervisor.

------
anonymousDan
I think rump kernels are definitely the future. It will be interesting to see
if any of the other *nixes attempt to reorganize their kernels a la NetBSD to
make them potentially useable as rump kernels.

~~~
vezzy-fnord
Personally I'd like to see the monolithic Unixes get decomposed into
multiserver, as was attempted with the IBM SawMill project in the late 90s for
Linux.

~~~
noselasd
Personally I much rather like the approach Plan 9 took to decomposition vs
what SawMill attempted.

~~~
vezzy-fnord
Going the Plan 9 way would be a blank state reset of everything, doing a
retroactive modularization would retain the existing environment.

------
macavity23
This looks great. Hopefully this can be configured to set off a big fat alarm
if any unexpected syscalls get called. Will be a huge security win.

~~~
cpuguy83
Well, seccomp already does this, no?

------
yeukhon
So what if I need to run centos and ubuntu containers on a centos host?

