An introduction to Clear Containers [LWN.net]

An introduction to Clear Containers

Posted May 19, 2015 13:28 UTC (Tue) by arjan (subscriber, #36785)
In reply to: An introduction to Clear Containers by balbir_singh
Parent article: An introduction to Clear Containers

the link you gave points at a microkernel project.

I have heard microkernel folks say two things
1) A microkernel is faster/more efficient
and
2) A microkernel is more secure (smaller surface)

I think 1) is pretty much debunked at this point with this article, but it's hard to argue with 2)... less functionality also leaves less to attack.

to post comments

An introduction to Clear Containers

Posted May 19, 2015 16:03 UTC (Tue) by edomaur (subscriber, #14520) [Link] (1 responses)

MirageOS is more than just a microkernel, it's what is called an "unikernel" or a "vmlib" or a "vmstub". The idea, is to compile the application directly into a VM, with only the basic support from a custom kernel.

An introduction to Clear Containers

Posted May 20, 2015 14:26 UTC (Wed) by edomaur (subscriber, #14520) [Link]

Well, it sounds a bit pedantic, sorry about that.

However, after having looked a bit at Clear Container, I would like to say that it's a bit like MirageOS in the resulting VM : something lightweight, with minimalistic OS.

MirageOS and rump kernels

Posted May 26, 2015 21:10 UTC (Tue) by mato (guest, #964) [Link]

MirageOS[1] is not a microkernel. It is a "unikernel" or "Library operating system". Compared to traditional operating systems, your application and the kernel functionality needed to run it are linked together and run in a single address space.

I would also like to point out our work (disclaimer: I'm one of the core developers) on rump kernels[2] and the rumprun unikernel stack[3] which allows you to run existing, unmodified, POSIX applications as unikernels on KVM, Xen and bare metal.

I like to think of our (Mirage and rump kernels) approach as doing away with the traditional operating system altogether; it's the ultimate in minimalism. Only include the functionality required to get your application to run and nothing else.

This has several interesting advantages:

- We've all seen the various bugs found in the industry standard TLS stack. The Mirage folks have developed green-field type-safe implementations of the entire TCP, HTTP and TLS stack in OCaml. They've put up a bounty in the form of the BTC Piñata[4]. If you can break their stack, you get to keep the bitcoin.
- Containers (and Clear Containers) still include an entire operating system, accessible to the application running on it, and thus potentially exploitable. Compare that to running your application on rumprun, which has no concept of exec(). If there's no shell to exec() then there's nothing to break into.
- A combination of Mirage and rumprun paves the way to the best of both worlds. Run a Mirage frontend serving HTTP and TLS, and talk to a rumprun unikernel running (for example) your legacy PHP application.

[1] https://mirage.io/
[2] http://rumpkernel.org/
[3] http://repo.rumpkernel.org/rumprun
[4] http://ownme.ipredator.se/