36c3 intro
Herald: Good morning again. Thanks. First off for today is by Hannes Mehnert. It's
titled "Leaving Legacy Behind". It's about the reduction of carbon footprint through
micro kernels in MirageOS. Give a warm welcome to Hannes.
Applause
Hannes Mehnert: Thank you. So let's talk a bit about legacy, so legacy we had have.
Nowadays we run services usually on a Unix based operating system, which is
demonstrated here on the left a bit the layering. So at the lowest layer we have
the hardware. So some physical CPU, some lock devices, maybe a network interface
card and maybe some memories, some non- persistent memory. On top of that, we
usually run the Unix kernel. So to say. That is marked here in brown which is
which consists of a filesystem. Then it has a scheduler, it has some process
management that has network stacks. So the TCP/IP stack, it also has some user
management and hardware and drivers. So it has drivers for the physical hard drive,
for their network interface and so on. The ground stuff. So the kernel runs in
privilege mode. It exposes a system called API or and/or a socket API to the
actual application where we are there to run, which is here in orange. So the
actual application is on top, which is the application binary and may depend on some
configuration files distributed randomly across the filesystem with some file
permissions set on. Then the application itself also depends likely on a programming
language runtime that may either be a Java virtual machine if you run Java or Python
interpreter if you run Python, or a ruby interpreter if you run Ruby and so on.
Then additionally we usually have a system library. Lip C which is just runtime
library basically of the C programming language and it exposes a much nicer
interface than the system calls. We may as well have open SSL or another crypto
library as part of the application binary which is also here in Orange. So what's a
drop of the kernel? So the brown stuff actually has a virtual memory subsystem
and it should separate the orange stuff from each other. So you have multiple
applications running there and the brown stuff is responsible to ensure that the
orange that different pieces of orange stuff don't interfere with each other so
that they are not randomly writing into each other's memory and so on. Now if the
orange stuff is compromised. So if you have some attacker from the network or
from wherever else who's able to find a flaw in the orange stuff, the kernel is still
responsible for strict isolation between the orange stuff. So as long as the
attacker only gets access to the orange stuff, it should be very well contained.
But then we look at the bridge between the brown and orange stuff. So between kernel
and user space and there we have an API which is roughly 600 system calls at
least on my FreeBSD machine here in Sys calls. So it's 600 different functions or
the width of this API is 600 different functions, which is quite big. And it's
quite easy to hide some flaws in there. And as soon as you're able to find a flaw
in any of those system calls, you can escalate your privileges and then you
basically run into brown moats and kernel mode and you have access to the raw
physical hardware. And you can also read arbitrary memory from any processor
running there. So now over the years it actually evolved and we added some more
layers, which is hypervisors. So at the lowest layer, we still have the hardware
stack, but on top of the hardware we now have a hypervisor, which responsibility it
is to split the physical hardware into pieces and slice it up and run different
virtual machines. So now we have the byte stuff, which is the hypervisor. And on top
of that, we have multiple brown things and multiple orange things as well. So now the
hypervisor is responsible for distributing the CPUs to virtual machines. And the
memory to virtual machines and so on. It is also responsible for selecting which
virtual machine to run on which physical CPU. So it actually includes the scheduler
as well. And the hypervisors responsibility is again to isolate the
different virtual machines from each other. Initially, hypervisors were done
mostly in software. Nowadays, there are a lot of CPU features available, which
allows you to have some CPU support, which makes them fast, and you don't have to
trust so much software anymore, but you have to trust in the hardware. So that's
extended page tables and VTD and VTX stuff. OK, so that's the legacy we have
right now. So when you ship a binary, you actually care about some tip of the
iceberg. That is the code you actually write and you care about. You care about
deeply because it should work well and you want to run it. But at the bottom you have
the sole operating system and that is the code. The operating system insist that you
need it. So you can't get it without the bottom of the iceberg. So you will always
have a process management and user management and likely as well the
filesystem around on a UNIX system. Then in addition, back in May, I think their
was a blog entry from someone who analyzed from Google Project Zero, which is a
security research team and red team which tries to fund a lot of flaws in vitally
use applications . And they found in a year maybe 110 different vulnerabilities
which they reported and so on. And someone analyzed what these 110 vulnerabilities
were about and it turned out that more than two thirds of them, that the root
cause of the flaw was memory corruption. And memory corruption means arbitrary
reads of rights from from arbitrary memory, which a process that's not
supposed to be in. So why does that happen? That happens because we on the
Unix system, we mainly use program languages where we have tight control over
the memory management. So we do it ourselves. So we allocate the memory
ourselves and we free it ourselves. There is a lot of boilerplate we need to write
down and that is also a lot of boilerplate which you can get wrong. So now we talked
a bit about legacy. Let's talk about the goals of this talk. The goals is on the
one side to be more secure. So to reduce the attack vectors because C and languages
like that from the 70s and we may have some languages from the 80s or even from
the 90s who offer you automated memory management and memory safety languages
such as Java or Rust or Python or something like that. But it turns out not
many people are writing operating systems in those languages. Another point here is
I want to reduce the attack surface. So we have seen this huge stack here and I want
to minimize the orange and the brown part. Then as an implication of that. I also
want to reduce the runtime complexity because that is actually pretty cumbersome
to figure out what is now wrong. Why does your application not start? And if the
whole reason is because some file on your harddisk has the wrong filesystem
permissions, then it's pretty hard to get across if you're not yet a Unix expert
who has a lift in the system for years or at least months. And then the final goal,
thanks to the topic of this conference and to some analysis I did, is to actually
reduce the carbon footprint. So if you run a service, you certainly that service does
some computation and this computation takes some CPU takes. So it takes some CPU
time in order to be evaluated. And now reducing that means if you condense down
the complexity and the code size, we also reduce the amount of computation which
needs to be done. These are the goals. So what are MirageOS unikernels? That is
basically the project i have been involved in since six years or so. The general idea
is that each service is isolated in a separate MirageOS unikernel. So your DNS
resover or your web server don't run on this general purpose UNIX system as a
process, but you have a separate virtual machine for each of them. So you have one
unikernel which only does DNS resolution and in that unikernel you don't even need
a user management. You don't even need process management because there's only a
single process. There's a DNS resolver. Actually, a DNS resolver also doesn't
really need a file system. So we got rid of that. We also don't really need virtual
memory because we only have one process. So we don't need virtual memory and we
just use a single address space. So everything is mapped in a single address
space. We use program language called OCaml, which is functional programming
language which provides us with memory safety. So it has automated memory
measurement and we use this memory management and the isolation, which the
program manager guarantees us by its type system. We use that to say, okay, we can
all live in a single address space and it'll still be safe as long as the
components are safe. And as long as we minimize the components which are by
definition unsafe. So we need to run some C code there as well. So in addition,
well. Now, if we have a single service, we only put in the libraries or the stuff we
actually need in that service. So as I mentioned that the DNS resolver won't need
a user management, it doesn't need a shell. Why would I need to shell? What
should I need to do there? And so on. So we have a lot of libraries, a lot of OCaml
libraries which are picked by the single servers or which are mixed and matched for
the different services. So libraries are developed independently of the whole
system or of the unikernel and are reused across the different components or across
the different services. Some further limitation which I take as freedom and
simplicity is not even we have a single address space. We are also only focusing
on single core and have a single process. So we don't have a process. We don't know
the concept of process yet. We also don't work in a preemptive way. So preemptive
means that if you run on a CPU as a function or as a program, you can at any
time be interrupted because something which is much more important than you can
now get access to the CPU. And we don't do that. We do co-operative tasks. So we are
never interrupted. We don't even have interrupts. So there are no interrupts.
And as I mentioned, it's executed as a virtual machine. So how does that look
like? So now we have the same picture as previously. We have at the bottom the
hypervisor. Then we have the host system, which is the brownish stuff. And on top of
that we have maybe some virtual machines. Some of them run via KVM and qemu UNIX
system. Using some Virtio that is on the right and on the left. And in the middle
we have this MirageOS as Unicode where we and the whole system don't run any qemu,
but we run a minimized so-called tender, which is this solo5-hvt monitor process.
So that's something which just tries to allocate or will allocate some host system
resources for the virtual machine and then does interaction with the virtual machine.
So what does this solo5-hvt do in this case is to set up the memory, load the
unikernel image which is a statically linked ELF binary and it sets up the
virtual CPU. So the CPU needs some initialization and then booting is jumped
to an address. It's already in 64 bit mode. There's no need to boot via 16 or 32 bit
modes. Now solo5-hvt and the MirageOS they also have an interface and the interface
is called hyper calls and that interface is rather small. So it only contains in
total 14 different functions. Which main function yields a way to get the argument
vector clock. Actually, two clocks, one is a POSIX clock, which takes care of this
whole time stamping and timezone business and another one in a monotonic clock which
by its name guarantees that time will pass monotonically. Then the other console
interface. The console interface is only one way. So we only output data. We never
read from console. A block device. Well a block devices and network interfaces and
that's all the hyper calls we have. To look a bit further down into detail of how
a MirageOS unikernel looks like. Here I pictured on the left again the tender at
the bottom, and then the hyper calls. And then in pink I have the pieces of code
which still contain some C code and the MirageOS unikernel. And in green I have
the pieces of code which does not include any C code, but only OCaml code. So
looking at the C code which is dangerous because in C we have to deal with memory
management on our own, which means it's a bit brittle. We need to carefully review
that code. It is definitely the OCaml runtime which we have here, which is round
25 thousand lines of code. Then we have a library which is called nolibc which is
basically a C library which implements malloc and string compare and some
basic functions which are needed by the OCaml runtime. That's roughly 8000 lines
of code. That nolibc also provides a lot of stops which just exit to or return
null for the OCaml runtime because we use an unmodified OCaml runtime to be able to
upgrade our software more easily. We don't have any patents for The OCaml runtime.
Then we have a library called solo5-bindings, which is basically
something which translates into hyper calls or which can access a hyper calls
and which communicates with the host system via hyper calls. That is roughly
2000 lines of code. Then we have a math library for sinus and cosinus and tangents
and so on. And that is just the openlibm which is originally from the freeBSD
project and has roughly 20000 lines of code. So that's it. So I talked a bit
about solo5, about the bottom layer and I will go a bit more into detail about the
solo5 stuff, which is really the stuff which you run at the bottom
of the MirageOS. There's another choice. You can also run Xen or Qubes OS at
the bottom of the MirageOS unikernel. But I'm focusing here mainly on solo5. So
solo5 has a sandbox execution environment for unikernels. It handles resources from
the host system, but only aesthetically. So you say at startup time how much memory
it will take. How many network interfaces and which ones are taken and how many
block devices and which ones are taken by the virtual machine. You don't have any
dynamic resource management, so you can't add at a later point in time a new network
interface. That's just not supported. And it makes the code much easier. We don't even
have dynamic allocation inside of solo5. We have a hyper cool interface. As I
mentioned, it's only 14 functions. We have bindings for different targets. So we can
run on KVM, which is hypervisor developed for the Linux project, but also for
Beehive, which is a free BSD hypervisor or VMM which is openBSD hypervisor. We also
target other systems such as the g-node, wich is an operating system, based on a
micro kernel written mainly in C++, virtio, which is a protocol usually spoken
between the host system and the guest system, and virtio is used in a lot of
cloud deployments. So it's OK. So qemu for example, provides you with a virtio
protocol implementation. And a last implementation of solo5 or bindings for
solo5 is seccomb. So Linux seccomb is a filter in the Linux kernel where you can
restrict your process that will only use a certain number or a certain amount of
system calls and we use seccomb so you can deploy it without virtual machine in the
second case, but you are restricted to which system calls you can use. So solo5
also provides you with the host system tender where applicable. So in the virtio
case it not applicable. In the g-note case it is also not applicable. In KVM we
already saw the solo5 HVT, wich is a hardware virtualized tender. Which is just
a small binary because if you run qemu at least hundreds of thousands of lines of
code in the solo5 HVT case, it's more like thousands of lines of code. So here we
have a comparison from left to right of solo5 and how the host system or the host
system kernel and the guest system works. In the middle we have a virtual machine, a
common Linux qemu KVM based virtual machine for example, and on the right hand
we have the host system and the container. Container is also a technology where you
try to restrict as much access as you can from process. So it is contained and the
potential compromise is also very isolated and contained. On the left hand side we
see that solo5 is basically some bits and pieces in the host system. So is the solo5
HVT and then some bits and pieces in Unikernel. So is the solo5 findings I
mentioned earlier. And that is to communicate between the host and the guest
system. In the middle we see that the API between the host system and the virtual
machine. It's much bigger than this. And commonly using virtio and virtio is really
a huge protocol which does feature negotiation and all sorts of things where
you can always do something wrong, like you can do something wrong and a floppy
disk driver. And that led to some exploitable vulnerability, although
nowadays most operating systems don't really need a floppy disk drive anymore.
And on the right hand side, you can see that the whole system interface for a
container is much bigger than for a virtual machine because the whole system
interface for a container is exactly those system calls you saw earlier. So it's run
600 different calls. And in order to evaluate the security, you need basically
to audit all of them. So that's just a brief comparison between those. If we look
into more detail, what solo5 what shapes it can have here on the left side. We can
see it running in a hardware virtualized tender, which is you have the Linux
freebies, your openBSD at the bottom and you have solo5 blob, which is a blue thing
here in the middle. And then on top you have the unikernel. On the right hand side
you can see the Linux satcom process and you have a much smaller solo5 blob because
it doesn't need to do that much anymore, because all the hyper calls are basically
translated to system calls. So you actually get rid of them and you don't
need to communicate between the host and the guest system because in seccomb you
run as a whole system process so you don't have this virtualization. The advantage of
using seccomb as well, but you can deploy it without having access to virtualization
features of the CPU. Now to get it in even smaller shape. There's another backend I
haven't talked to you about. It's called the Muen. It's a separation kernel
developed in Ada. So you basically ... so now we try to get rid of this huge Unix
system below it. Which is this big kernel thingy here. And Muen is an open source
project developed in Switzerland in Ada, as I mentioned, and that uses SPARK, which
is proof system, which guarantees the memory isolation between the different
components. And Muen now goes a step further and it says, "Oh yeah. For you as
a guest system, you don't do static allocations and you don't do dynamic
resource management." We as a host system, we as a hypervisor, we don't do any
dynamic resource allocation as well. So it only does static resource management. So
at compile time of your Muen separation kernel you decide how many virtual
machines or how many unikernels you are running and which resources are given to
them. You even specify which communication channels are there. So if one of your
virtual machines needs to talk to another one, you need to specify that at
compile time and at runtime you don't have any dynamic resource management. So that
again makes the code much easier, much, much less complex. And you get to much
fewer lines of code. So to conclude with this Mirage and how this and also the Muen
and solo5. And how that is. I like to cite Antoine: "Perfection is achieved, not when
there is nothing more to add, but when there is nothing left to take away." I
mean obviously the most secure system is a system which doesn't exist.
Laughter
Let's look a bit further
into the decisions of MirageOS. Why do you use this strange
programming language called OCaml and what's it all about? And what are the case
studies? So OCaml has been around since more than 20 years. It's a multi paradigm
programming language. The goal for us and for OCaml is usually to have declarative
code. To achieve declarative code you need to provide the developers with some
orthogonal abstraction facilities such as here we have variables then functions you
likely know if you're a software developer. Also higher order functions. So
that just means that the function is able to take a function as input. Then in OCaml
we tried to always focus on the problem and do not distract with boilerplate. So
some running example again would be this memory management. We don't manually deal
with that, but we have computers to actually deal with that. In OCaml you have
a very expressive and static type system, which can spot a lot of invariance or
violation of invariance at build time. So the program won't compile if you don't
handle all the potential return types or return values of your function. So now a
type system, you know, you may know it from Java is a bit painful. If you have to
express at every location where you want to have a variable, which type this
variable is. What OCaml provides is type inference similar to Scala and other
languages. So you don't need to type all the types manually. And types are also
unlike in Java. Types are erased during compilation. So types are only information
about values the compiler has at compile time. But at runtime these are all erased
so they don't exist. You don't see them. And OCaml compiles to native machine code,
which I think is important for security and performance. Because otherwise you run
an interpreter or an abstract machine and you have to emulate something else and
that is never as fast as you can. OCaml has one distinct feature, which is its
module system. So you have all your values, which types or functions. And now
each of those values is defined inside of a so-called module. And the simplest
module is just the filename. But you can nest modules so you can explicitly say, oh
yeah, this value or this binding is now living in a sub module here off. So each
module you can also give it a type. So it has a set of types and a set of functions
and that is called its signature, which is the interface of the module. Now you have
another abstraction mechanism in OCaml which is functors. And functors are
basically compile time functions from module to module. So they allow a
pyramidisation. Like you can implement your generic map structure and all you
require. So map is just a hash map or a implementation is maybe a binary tree. And
you need to have is some comparison for the keys and that is modeled in OCaml by
module. So you have a module called map and you have a functor called make. And the
make takes some module which implements this comparison method and then provides
you with map data structure for that key type. And then MirageOS we actually use a
module system quite a bit more because we have all these resources which are
different between Xen and KVM and so on. So each of the different resources like a
network interface has a signature. OK, and target specific implementation. So we have
the TCP/IP stack, which is much higher than the network card, but it doesn't
really care if you run on Xen or if you run on KVM. You just program against this
abstract interface against the interface of the network device. But you don't need
to program. You don't need to write in your TCP/IP stack any code to run on Xen
or to run on KVM. So MirageOS also doesn't really use the complete OCaml
programming language. OCaml also provides you with an object system and we barely
use that. We also have in MirageOS... well OCaml also allows you for with mutable
state. And we barely used that mutable state, but we use mostly immutable data
whenever sensible. We also have a value passing style, so we put state and data as
inputs. So stage is just some abstract state and data is just a byte vector
in a protocol implementation. And then the output is also a new state which may be
modified and some reply maybe so some other byte vector or some application
data. Or the output data may as well be an error because the incoming data and state
may be invalid or might maybe violate some some constraints. And errors are also
explicitly types, so they are declared in the API and the call of a function needs
to handle all these errors explicitly. As I said, the single core, but we have some
promise based or some even based concurrent programming stuff. And yeah, we
have the ability to express a really strong and variants like this is a read-
only buffer in the type system. And the type system is, as I mentioned, only
compile time, no runtime overhead. So it's all pretty nice and good. So let's take a
look at some of the case studies. The first one is unikernel. So it's called the
Bitcoin Pinata. It started in 2015 when we were happy with from the scratch developed
TLS stack. TLS is transport layer security. So what use if you browse to
HTTPS. So we have an TLS stack in OCaml and we wanted to do some marketing for
that. Bitcoin Pinata is basically unikernel which uses TLS and provides you
with TLS endpoints, and it contains the private key for a bitcoin wallet which is
filled with, which used to be filled with 10 bitcoins. And this means it's a
security bait. So if you can compromise the system itself, you get the private key
and you can do whatever you want with it. And being on this bitcoin block chain, it
also means it's transparent so everyone can see that that has been hacked or not.
Yeah and it has been online since three years and it was not hacked. But the bitcoin we
got were only borrowed from friends of us and they were then reused in other
projects. It's still online. And you can see here on the right that we had some
HTTP traffic, like an aggregate of maybe 600,000 hits there. Now I have a size
comparison of the Bitcoin Pinata on the left. You can see the unikernel, which is
less than 10 megabytes in size or in source code it's maybe a hundred thousand
lines of code. On the right hand side you have a very similar thing, but running as
a Linux service so it runs an openSSL S server, which is a minimal TLS server you
can get basically on a Linux system using openSSL. And there we have mainly maybe a
size of 200 megabytes and maybe two million two lines of code. So that's
roughly a vector of 25. In other examples, we even got a bit less code, much bigger
effect. Performance analysis I showed that ... Well, in 2015 we did some evaluation
of our TLS stack and it turns out we're in the same ballpark as other
implementations. Another case study is CalDAV server, which we developed last
year with a grant from Prototypefund which is a German government funding. It is
intolerable with other clients. It stores data in a remote git repository. So we
don't use any block device or persistent storage, but we store it in a git
repository so whenever you add the calendar event, it does actually a git
push. And we also recently got some integration with CalDAV web, which is a
JavaScript user interface doing in JavaScript, doing a user interface. And we
just bundle that with the thing. It's online, open source, there is a demo
server and the data repository online. Yes, some statistics and I zoom in
directly to the CPU usage. So we had the luck that we for half of a month, we used
it as a process on a freeBSD system. And that happened roughly the first half until
here. And then at some point we thought, oh, yeah, let's migrated it to MirageOS
unikernel and don't run the freeBSD system below it. And you can see here on the x
axis the time. So that was the month of June, starting with the first of June on
the left and the last of June on the right. And on the y axis, you have the
number of CPU seconds here on the left or the number of CPU ticks here on the right.
The CPU ticks are virtual CPU ticks which debug counters from the hypervisor.
So from beehive and freeBSD here in that system. And what you can see here is this
massive drop by a factor of roughly 10. And that is when we switched from a Unix
virtual machine with the process to a freestanding Unikernel. So we actually use
much less resources. And if we look into the bigger picture here, we also see that
the memory dropped by a factor of 10 or even more. This is now a logarithmic scale
here on the y axis, the network bandwidth increased quite a bit because now we do
all the monitoring traffic, also via net interface and so on. Okay, that's CalDAV.
Another case study is authoritative DNS servers. And I just recently wrote a
tutorial on that. Which I will skip because I'm a bit short on time. Another
case study is a firewall for QubesOS. QubesOS is a reasonable, secure operating
system which uses Xen for isolation of workspaces and applications such as PDF
reader. So whenever you receive a PDF, you start your virtual machine, which is only
run once and you, well which is just run to open and read your PDF. And Qubes Mirage
firewall is now small or a tiny replacement for the Linux based firewall
written in OCaml now. And instead of roughly 300mb, you only use 32mb
of memory. There's now also recently some support for dynamic firewall rules
as defined by Qubes 4.0. And that is not yet merged into master, but it's under
review. Libraries in MirageOS yeah we have since we write everything from scratch and
in OCaml we don't have now. We don't have every protocol, but we have quite a few
protocols. There are also more unikernels right now, which you can see here in the
slides. Also online in the Fahrplan so you can click on the links later. Repeaters
were built. So for security purposes we don't get shipped binaries. But I plan to
ship binaries and in order to ship binaries. I don't want to ship non
reputable binaries. What is reproducible builds? Well it means that if you have the
same source code, you should get the binary identical output. And issues are
temporary filenames and timestamps and so on. In December we managed in MirageOS to
get some tooling on track to actually test the reproducibility of unikernels and we
fixed some issues and now all the tests in MirageOS unikernels reporducable, which
are basically most of them from this list. Another topic, a supply chain security,
which is important, I think, and we have this is still a work in progress. We still
haven't deployed that widely. But there are some test repositories out there to
provide more, to provide signatures signed by the actual authors of a library and
getting you across until the use of the library can verify that. And some
decentralized authorization and delegation of that. What about deployment? Well, in
conventional orchestration systems such as Kubernetes and so on. We don't yet have
a proper integration of MirageOS, but we would like to get some proper integration
there. If you already generate some libvirt.xml files from Mirage. So for each
unikernel you get the libvirt.xml and you can do that and run that in your libvirt
based orchestration system. For Xen, we also generate those .xl and .xe files,
which I personally don't really know much about, but that's it. On the
other side, I developed an orchestration system called Albatross because I was a
bit worried if I now have those tiny unikernels which are megabytes in size
and now I should trust the big Kubernetes, which is maybe a million lines of code
running on the host system with privileges. So I thought, oh well let's
try to come up with a minimal orchestration system which allows me some
console access. So I want to see the debug messages or whenever it fails to boot I
want to see the output of the console. Want to get some metrics like the Graphana
screenshot you just saw. And that's basically it. Then since I developed also
a TLS stack, I thought, oh yeah, well why not just use it for remote deployment? So
in TLS you have mutual authentication, you can have client certificates and
certificate itself is more or less an authenticated key value store because you
have those extensions and X 509 version 3 and you can put arbitrary data in there
with keys being so-called object identifiers and values being whatever
else. TLS certificates have this great advantage that or X 509 certificates have
the advantage that during a TLS handshake they are transferred on the wire in not
base64 or PEM encoding as you usually see them, but in basic encoding which is much
nicer to the amount of bits you transfer. So it's not transferred in base64, but
directly in raw basically. And with Alabtross you can basically do a TLS
handshake and in that client certificate you present, you already have the
unikernel image and the name and the boot arguments and you just deploy it directly.
You can alter an X 509. You have a chain of certificate authorities, which you send
with and this chain of certificate authorities also contain some extensions
in order to specify which policies are active. So how many virtual machines are
you able to deploy on my system? How much memory you you have access to and which
bridges or which network interfaces you have access to? So Albatross is really a
minimal orchestration system running as a family of Unix processes. It's maybe 3000
lines of code or so. OCaml code. But using then the TLS stack and so on. But yeah, it
seems to work pretty well. I at least use it for more than two dozen unikernels at
any point in time. What about the community? Well the whole MirageOS project
started around 2008 at University of Cambridge, so it used to be a research
project with which still has a lot of ongoing student projects at University of
Cambridge. But now it's an open source permissive license, mostly BSD licensed
thing, where we have community event every half a year and a retreat in Morocco where
we also use our own unikernels like the DHTP server and the DNS resolve and so on.
We just use them to test them and to see how does it behave and does it work for
us? We have quite a lot of open source computer contributors from all over and
some of the MirageOS libraries have also been used or are still used in this Docker
technology, Docker for Mac and Docker for Windows, which emulates the guest system
or which needs some wrappers. And there is a lot of OCaml code is used. So to finish
my talk, I would like to have another side, which is that Rome wasn't built in a
day. So where we are is to conclude here we have a radical approach to operating
systems development. We have a security from the ground up with much fewer code
and we also have much fewer attack vectors because we use a memory safe
language. So we have reduced the carbon footprint, as I mentioned in the start of
the talk, because we use much less CPU time, but also much less memory. So we use
less resources. MirageOS itself and O'Caml have a reasonable performance. We have
seen some statistics about the TLS stack that it was in the same ballpark as
OpenSSL and PolarSSL, which is nowadays MBed TLS, and MirageOS unikernels, since
they don't really need to negotiate features and wait for the Scottie Pass and
so on. They actually do it in milliseconds, not in seconds, so they do
not hardware probing and so on. But they know that startup time what they expect. I
would like to thank everybody who is and was involved in this whole technology
stack because I myself I program quite a bit of O'Caml, but I wouldn't have been
able to do that on my own. It is just a bit too big. MirageOS currently spends
around maybe 200 different git repositories with the libraries, mostly
developed on GitHub and open source. I am at the moment working in a nonprofit
company in Germany, which is called the Center for the Cultivation of Technology
with a project called robur. So we work in a collective way to develop full-stack
MirageOS unikernels. That's why I'm happy to do that from Dublin. And if you're
interested, please talk to us. I have some selected related talks, there are much
more talks about MirageOS. But here is just a short list of something, if you're
interested in some certain aspects, please help yourself to view them.
That's all from me.
Applause
Herald: Thank you very much. There's a bit over 10 minutes of time for questions. If
you have any questions go to the microphone. There's several microphones
around the room. Go ahead. Question: Thank you very much for the talk
- Herald: Writ of order. Thanking the
speaker can be done afterwards. Questions are questions, so short sentences ending
with a question mark. Sorry, do go ahead. Question: If I want to try this at home,
what do I need? Is a raspi sufficient? No, it isn't.
Hannes: That is an excellent question. So I usually develop it on such a thinkpad
machine, but we actually support also ARM64 mode. So if you have a Raspberry Pi
3+, which I think has the virtualization bits and the Linux kernel, which is reason
enough to support KVM on that Raspberry Pi 3+, then you can try it out there.
Herald: Next question. Question: Well, currently most MirageOS
unikernels are used for running server applications. And so obviously this all
static preconfiguration of OCaml and maybe Ada SPARK is fine for that. But what
do you think about... Will it ever be possible to use the same approach with all
this static reconfiguration for these very dynamic end user desktop systems, for
example, like which at least currently use quite a lot of plug-and-play.
Hannes: Do you have an example? What are you thinking about?
Question: Well, I'm not that much into the topic of its SPARK stuff, but you said
that all the communication's paths have to be defined in advance. So especially with
plug-and-play devices like all this USB stuff, we either have to allow everything
in advance or we may have to reboot parts of the unikernels in between to allow
rerouting stuff. Hannes: Yes. Yes. So I mean if you want to
design a USB plug-and-play system, you can think of it as you plug in somewhere the
USB stick and then you start the unikernel which only has access to that USB stick.
But having a unikernel... Well I wouldn't design a unikernel which randomly does
plug and play with the the outer world, basically. So. And one of the applications
I've listed here is at the top is a picture viewer, which is a unikernel that
also at the moment, I think has static embedded data in it. But is able on Qubes
OS or on Unix and SDL to display the images and you can think of some way we
are a network or so to access the images actually. So you didn't need to compile
the images in, but you can have a good repository or TCP server or whatever in
order to receive the images. So I am saying. So what I didn't mention is that
MirageOS instead of being general purpose and having a shell and you can do
everything with it, it is that each service, each unikernel is a single
service thing. So you can't do everything with it. And I think that is an advantage
from a lot of points of view. I agree that if you have a highly dynamic system,
that you may have some trouble on how to integrate that.
Herald: Are there any other questions? No, it appears not. In which case,
thank you again, Hannes. Warm applause for Hannes.
Applause
Outro music
subtitles created by c3subtitles.de in the year 2020. Join, and help us!