
IncludeOS: A minimal, resource efficient unikernel for cloud systems - ingve
http://blog.acolyer.org/2016/02/22/includeos/
======
agentultra
> A DNS service built with IncludeOS results in a 158K disk image (for
> comparison, the MirageOS DNS server image came in at 200K).

A 42K difference and OCaml buys you memory safety and the ability to embed an
invariant in your type system; further restricting the allowable executions of
your program.

That is the point of MirageOS. They chose a functional language because they
wanted a trusted computing base (or something as practically close to trusted
as one can get).

I don't think _size_ is going to be the big determining factor for people
choosing competing unikernel implementations.

~~~
cheez
The problem I see with these unikernels is that they all necessarily have to
reimplement things that have had decades of testing like TCP/IP stacks. This
could be problematic and contain MORE vulnerabilities than the alternative.

So I would say that the factors in a decision to use a unikernel are likely:

    
    
      1. Speed/cost
      2. Space
      3. Security (or lack thereof)
    

I would guess that the cost difference needs to be so convincing that people
will be willing to work around potential security issues.

~~~
agentultra
I don't technically have a horse in the unikernel race but have only been
following the MirageOS team.

From what I understand unikernels or "operating system as a library," are not
not a new idea. The cost of implementing an entire TCP/IP stack for every
unikernel ecosystem is probably what kept them from being adopted early on.
However we have some good specifications these days and battle-hardened
implementations to test new ideas against. I think the idea behind MirageOS is
that they see C/glibc/etc as a liability.

So building a TCP/IP stack in a pure-functional language is an interesting
idea. Just because we have a reliable system now doesn't mean we can't make it
more robust by experimenting with new ideas.

One certainly needs to take more care building unikernel infrastructure than a
typical web application or script. I'd only touch them in production with
verifiable formal specifications and a strongly-typed functional language
implementation... but that's light-years ahead of what a typical gnu/linux VM
guarantees.

(Also the reason why I don't think size will matter here is that they all aim
to be pretty small and in a cloud, 42KB difference on HVs with >64GB of RAM
doesn't make much of a difference)

~~~
cheez
It's true that unikernels, if done right, give you the possibility of formal
verification. So that would be a definite selling point for MirageOS as
opposed to IncludeOS. Can they do it, though?

~~~
agentultra
Probably... many of the people behind MirageOS are Cambridge-educated people.
I have no university degree and I'm picking up TLA+ as my first foray into
formal methods quite well. The amazing thing is that for _correctness_ the
maths behind TLA+ is really easy to understand. I think many people involved
in systems-level programming could pick it up with just a couple of weeks'
training.

I don't think they have done it though... which makes reading through their
TLS implementation rather difficult, IMO. The type system of OCaml will give
some guarantees but it has a hard time catching high-level design errors that
TLA+ and formal methods will.

 _update_ This also doesn't preclude them, or anyone with an interest, in
creating specifications for these systems. Amazon started using formal methods
and found bugs in several AWS services after the fact.

 _update update_ s/SSL/TLS/

------
ingve
Notable updates since the paper was published [0]:

\- switched from GCC to LLVM/Clang-based toolchain

\- switched from EASTL to LLVM’s libc++

\- read-only FAT file system

\- exceptions implemented

\- working TCP

[0]
[http://blog.acolyer.org/2016/02/22/includeos/#comment-6419](http://blog.acolyer.org/2016/02/22/includeos/#comment-6419)

------
chflags
Would be nice if we could run images in Bochs. Possible? Less overhead than
having to install Qemu, which has grown to be quite heavy, IMHO.

~~~
AlfredBratterud
I wrote the bootloader and first kernel sketch using Bochs exclusively, due to
the nice GUI for register inspection, instruction-by-instruction stepping etc.
But it hasn't been tested on bochs for ages, so now I don't know. In
particular I have never done any networking with bochs; my guess is that if it
has virtio it would be pretty easy to support it. Go ahead and try, let's know
how far it gets and we'll help you out :-)

------
anonymousDan
So how does this differ from the work on lkl (the linux kernel library:
[https://www.researchgate.net/publication/224164682_LKL_The_L...](https://www.researchgate.net/publication/224164682_LKL_The_Linux_kernel_library))?
Is it that they're actually rewriting their own kernel components with the
goal of modularity/minimality?

~~~
justincormack
Yes, LKL uses unmodified Linux so you live with the dependencies and way the
functionality is implemented. In exchange you get working code right now.

Also Linux is GPL, while includeOS is Apache licensed. As a library, the
syscall exception may well not apply with using Linux as a unikernel.

------
amelius
Is it possible to "ssh" into an IncludeOS machine by default?

Does it include a filesystem?

Does it allow to execute other processes?

~~~
marssaxman
It's not a machine, exactly; it's not an OS in the way you are used to
thinking of it. It's a library you link against, which gives you a single,
statically linked, bootable image, which you can then launch inside a VM.
There is no shell, unless your application includes one; there is no
filesystem, unless your application implements one; there are no other
processes, unless your application chooses to manage them.

