1 00:00:00,000 --> 00:00:18,660 *36c3 intro* 2 00:00:18,660 --> 00:00:23,914 Herald: Good morning again. Thanks. First off for today is by Hannes Mehnert. It's 3 00:00:23,914 --> 00:00:29,390 titled "Leaving Legacy Behind". It's about the reduction of carbon footprint through 4 00:00:29,390 --> 00:00:33,230 micro kernels in MirageOS. Give a warm welcome to Hannes. 5 00:00:33,230 --> 00:00:39,250 *Applause* 6 00:00:39,250 --> 00:00:45,060 Hannes Mehnert: Thank you. So let's talk a bit about legacy, so legacy we had have. 7 00:00:45,060 --> 00:00:50,000 Nowadays we run services usually on a Unix based operating system, which is 8 00:00:50,000 --> 00:00:55,080 demonstrated here on the left a bit the layering. So at the lowest layer we have 9 00:00:55,080 --> 00:01:00,829 the hardware. So some physical CPU, some lock devices, maybe a network interface 10 00:01:00,829 --> 00:01:06,570 card and maybe some memories, some non- persistent memory. On top of that, we 11 00:01:06,570 --> 00:01:13,740 usually run the Unix kernel. So to say. That is marked here in brown which is 12 00:01:13,740 --> 00:01:19,580 which consists of a filesystem. Then it has a scheduler, it has some process 13 00:01:19,580 --> 00:01:25,470 management that has network stacks. So the TCP/IP stack, it also has some user 14 00:01:25,470 --> 00:01:32,350 management and hardware and drivers. So it has drivers for the physical hard drive, 15 00:01:32,350 --> 00:01:37,800 for their network interface and so on. The ground stuff. So the kernel runs in 16 00:01:37,800 --> 00:01:46,380 privilege mode. It exposes a system called API or and/or a socket API to the 17 00:01:46,380 --> 00:01:52,350 actual application where we are there to run, which is here in orange. So the 18 00:01:52,350 --> 00:01:56,460 actual application is on top, which is the application binary and may depend on some 19 00:01:56,460 --> 00:02:02,880 configuration files distributed randomly across the filesystem with some file 20 00:02:02,880 --> 00:02:08,119 permissions set on. Then the application itself also depends likely on a programming 21 00:02:08,119 --> 00:02:14,000 language runtime that may either be a Java virtual machine if you run Java or Python 22 00:02:14,000 --> 00:02:20,140 interpreter if you run Python, or a ruby interpreter if you run Ruby and so on. 23 00:02:20,140 --> 00:02:25,230 Then additionally we usually have a system library. Lip C which is just runtime 24 00:02:25,230 --> 00:02:30,790 library basically of the C programming language and it exposes a much nicer 25 00:02:30,790 --> 00:02:38,470 interface than the system calls. We may as well have open SSL or another crypto 26 00:02:38,470 --> 00:02:45,360 library as part of the application binary which is also here in Orange. So what's a 27 00:02:45,360 --> 00:02:50,200 drop of the kernel? So the brown stuff actually has a virtual memory subsystem 28 00:02:50,200 --> 00:02:55,110 and it should separate the orange stuff from each other. So you have multiple 29 00:02:55,110 --> 00:03:01,790 applications running there and the brown stuff is responsible to ensure that the 30 00:03:01,790 --> 00:03:07,150 orange that different pieces of orange stuff don't interfere with each other so 31 00:03:07,150 --> 00:03:12,601 that they are not randomly writing into each other's memory and so on. Now if the 32 00:03:12,601 --> 00:03:17,420 orange stuff is compromised. So if you have some attacker from the network or 33 00:03:17,420 --> 00:03:26,540 from wherever else who's able to find a flaw in the orange stuff, the kernel is still 34 00:03:26,540 --> 00:03:32,420 responsible for strict isolation between the orange stuff. So as long as the 35 00:03:32,420 --> 00:03:38,070 attacker only gets access to the orange stuff, it should be very well contained. 36 00:03:38,070 --> 00:03:42,650 But then we look at the bridge between the brown and orange stuff. So between kernel 37 00:03:42,650 --> 00:03:49,170 and user space and there we have an API which is roughly 600 system calls at 38 00:03:49,170 --> 00:03:56,360 least on my FreeBSD machine here in Sys calls. So it's 600 different functions or 39 00:03:56,360 --> 00:04:05,240 the width of this API is 600 different functions, which is quite big. And it's 40 00:04:05,240 --> 00:04:12,180 quite easy to hide some flaws in there. And as soon as you're able to find a flaw 41 00:04:12,180 --> 00:04:17,320 in any of those system calls, you can escalate your privileges and then you 42 00:04:17,320 --> 00:04:22,250 basically run into brown moats and kernel mode and you have access to the raw 43 00:04:22,250 --> 00:04:26,310 physical hardware. And you can also read arbitrary memory from any processor 44 00:04:26,310 --> 00:04:34,440 running there. So now over the years it actually evolved and we added some more 45 00:04:34,440 --> 00:04:39,350 layers, which is hypervisors. So at the lowest layer, we still have the hardware 46 00:04:39,350 --> 00:04:45,790 stack, but on top of the hardware we now have a hypervisor, which responsibility it 47 00:04:45,790 --> 00:04:51,300 is to split the physical hardware into pieces and slice it up and run different 48 00:04:51,300 --> 00:04:56,720 virtual machines. So now we have the byte stuff, which is the hypervisor. And on top 49 00:04:56,720 --> 00:05:04,360 of that, we have multiple brown things and multiple orange things as well. So now the 50 00:05:04,360 --> 00:05:12,320 hypervisor is responsible for distributing the CPUs to virtual machines. And the 51 00:05:12,320 --> 00:05:17,130 memory to virtual machines and so on. It is also responsible for selecting which 52 00:05:17,130 --> 00:05:21,660 virtual machine to run on which physical CPU. So it actually includes the scheduler 53 00:05:21,660 --> 00:05:28,950 as well. And the hypervisors responsibility is again to isolate the 54 00:05:28,950 --> 00:05:34,360 different virtual machines from each other. Initially, hypervisors were done 55 00:05:34,360 --> 00:05:39,889 mostly in software. Nowadays, there are a lot of CPU features available, which 56 00:05:39,889 --> 00:05:47,090 allows you to have some CPU support, which makes them fast, and you don't have to 57 00:05:47,090 --> 00:05:52,449 trust so much software anymore, but you have to trust in the hardware. So that's 58 00:05:52,449 --> 00:06:00,150 extended page tables and VTD and VTX stuff. OK, so that's the legacy we have 59 00:06:00,150 --> 00:06:08,070 right now. So when you ship a binary, you actually care about some tip of the 60 00:06:08,070 --> 00:06:12,229 iceberg. That is the code you actually write and you care about. You care about 61 00:06:12,229 --> 00:06:18,820 deeply because it should work well and you want to run it. But at the bottom you have 62 00:06:18,820 --> 00:06:23,830 the sole operating system and that is the code. The operating system insist that you 63 00:06:23,830 --> 00:06:30,180 need it. So you can't get it without the bottom of the iceberg. So you will always 64 00:06:30,180 --> 00:06:34,669 have a process management and user management and likely as well the 65 00:06:34,669 --> 00:06:41,100 filesystem around on a UNIX system. Then in addition, back in May, I think their 66 00:06:41,100 --> 00:06:48,900 was a blog entry from someone who analyzed from Google Project Zero, which is a 67 00:06:48,900 --> 00:06:54,540 security research team and red team which tries to fund a lot of flaws in vitally 68 00:06:54,540 --> 00:07:02,480 use applications . And they found in a year maybe 110 different vulnerabilities 69 00:07:02,480 --> 00:07:08,330 which they reported and so on. And someone analyzed what these 110 vulnerabilities 70 00:07:08,330 --> 00:07:13,660 were about and it turned out that more than two thirds of them, that the root 71 00:07:13,660 --> 00:07:18,940 cause of the flaw was memory corruption. And memory corruption means arbitrary 72 00:07:18,940 --> 00:07:22,880 reads of rights from from arbitrary memory, which a process that's not 73 00:07:22,880 --> 00:07:29,900 supposed to be in. So why does that happen? That happens because we on the 74 00:07:29,900 --> 00:07:36,160 Unix system, we mainly use program languages where we have tight control over 75 00:07:36,160 --> 00:07:40,199 the memory management. So we do it ourselves. So we allocate the memory 76 00:07:40,199 --> 00:07:44,639 ourselves and we free it ourselves. There is a lot of boilerplate we need to write 77 00:07:44,639 --> 00:07:53,190 down and that is also a lot of boilerplate which you can get wrong. So now we talked 78 00:07:53,190 --> 00:07:57,810 a bit about legacy. Let's talk about the goals of this talk. The goals is on the 79 00:07:57,810 --> 00:08:06,670 one side to be more secure. So to reduce the attack vectors because C and languages 80 00:08:06,670 --> 00:08:11,870 like that from the 70s and we may have some languages from the 80s or even from 81 00:08:11,870 --> 00:08:17,930 the 90s who offer you automated memory management and memory safety languages 82 00:08:17,930 --> 00:08:24,699 such as Java or Rust or Python or something like that. But it turns out not 83 00:08:24,699 --> 00:08:30,490 many people are writing operating systems in those languages. Another point here is 84 00:08:30,490 --> 00:08:37,159 I want to reduce the attack surface. So we have seen this huge stack here and I want 85 00:08:37,159 --> 00:08:45,880 to minimize the orange and the brown part. Then as an implication of that. I also 86 00:08:45,880 --> 00:08:50,410 want to reduce the runtime complexity because that is actually pretty cumbersome 87 00:08:50,410 --> 00:08:56,100 to figure out what is now wrong. Why does your application not start? And if the 88 00:08:56,100 --> 00:09:01,829 whole reason is because some file on your harddisk has the wrong filesystem 89 00:09:01,829 --> 00:09:09,560 permissions, then it's pretty hard to get across if you're not yet a Unix expert 90 00:09:09,560 --> 00:09:16,550 who has a lift in the system for years or at least months. And then the final goal, 91 00:09:16,550 --> 00:09:22,269 thanks to the topic of this conference and to some analysis I did, is to actually 92 00:09:22,269 --> 00:09:29,750 reduce the carbon footprint. So if you run a service, you certainly that service does 93 00:09:29,750 --> 00:09:37,629 some computation and this computation takes some CPU takes. So it takes some CPU 94 00:09:37,629 --> 00:09:44,759 time in order to be evaluated. And now reducing that means if you condense down 95 00:09:44,759 --> 00:09:49,860 the complexity and the code size, we also reduce the amount of computation which 96 00:09:49,860 --> 00:09:57,800 needs to be done. These are the goals. So what are MirageOS unikernels? That is 97 00:09:57,800 --> 00:10:07,459 basically the project i have been involved in since six years or so. The general idea 98 00:10:07,459 --> 00:10:14,309 is that each service is isolated in a separate MirageOS unikernel. So your DNS 99 00:10:14,309 --> 00:10:19,720 resover or your web server don't run on this general purpose UNIX system as a 100 00:10:19,720 --> 00:10:25,910 process, but you have a separate virtual machine for each of them. So you have one 101 00:10:25,910 --> 00:10:31,380 unikernel which only does DNS resolution and in that unikernel you don't even need 102 00:10:31,380 --> 00:10:35,759 a user management. You don't even need process management because there's only a 103 00:10:35,759 --> 00:10:41,720 single process. There's a DNS resolver. Actually, a DNS resolver also doesn't 104 00:10:41,720 --> 00:10:47,199 really need a file system. So we got rid of that. We also don't really need virtual 105 00:10:47,199 --> 00:10:52,259 memory because we only have one process. So we don't need virtual memory and we 106 00:10:52,259 --> 00:10:57,089 just use a single address space. So everything is mapped in a single address 107 00:10:57,089 --> 00:11:03,339 space. We use program language called OCaml, which is functional programming 108 00:11:03,339 --> 00:11:08,079 language which provides us with memory safety. So it has automated memory 109 00:11:08,079 --> 00:11:17,279 measurement and we use this memory management and the isolation, which the 110 00:11:17,279 --> 00:11:24,329 program manager guarantees us by its type system. We use that to say, okay, we can 111 00:11:24,329 --> 00:11:28,429 all live in a single address space and it'll still be safe as long as the 112 00:11:28,429 --> 00:11:34,579 components are safe. And as long as we minimize the components which are by 113 00:11:34,579 --> 00:11:42,639 definition unsafe. So we need to run some C code there as well. So in addition, 114 00:11:42,639 --> 00:11:47,660 well. Now, if we have a single service, we only put in the libraries or the stuff we 115 00:11:47,660 --> 00:11:51,699 actually need in that service. So as I mentioned that the DNS resolver won't need 116 00:11:51,699 --> 00:11:56,589 a user management, it doesn't need a shell. Why would I need to shell? What 117 00:11:56,589 --> 00:12:02,889 should I need to do there? And so on. So we have a lot of libraries, a lot of OCaml 118 00:12:02,889 --> 00:12:09,750 libraries which are picked by the single servers or which are mixed and matched for 119 00:12:09,750 --> 00:12:14,160 the different services. So libraries are developed independently of the whole 120 00:12:14,160 --> 00:12:20,010 system or of the unikernel and are reused across the different components or across 121 00:12:20,010 --> 00:12:26,910 the different services. Some further limitation which I take as freedom and 122 00:12:26,910 --> 00:12:32,839 simplicity is not even we have a single address space. We are also only focusing 123 00:12:32,839 --> 00:12:37,839 on single core and have a single process. So we don't have a process. We don't know 124 00:12:37,839 --> 00:12:46,679 the concept of process yet. We also don't work in a preemptive way. So preemptive 125 00:12:46,679 --> 00:12:52,790 means that if you run on a CPU as a function or as a program, you can at any 126 00:12:52,790 --> 00:12:58,019 time be interrupted because something which is much more important than you can 127 00:12:58,019 --> 00:13:03,970 now get access to the CPU. And we don't do that. We do co-operative tasks. So we are 128 00:13:03,970 --> 00:13:08,529 never interrupted. We don't even have interrupts. So there are no interrupts. 129 00:13:08,529 --> 00:13:13,480 And as I mentioned, it's executed as a virtual machine. So how does that look 130 00:13:13,480 --> 00:13:17,519 like? So now we have the same picture as previously. We have at the bottom the 131 00:13:17,519 --> 00:13:22,729 hypervisor. Then we have the host system, which is the brownish stuff. And on top of 132 00:13:22,729 --> 00:13:29,850 that we have maybe some virtual machines. Some of them run via KVM and qemu UNIX 133 00:13:29,850 --> 00:13:34,779 system. Using some Virtio that is on the right and on the left. And in the middle 134 00:13:34,779 --> 00:13:41,899 we have this MirageOS as Unicode where we and the whole system don't run any qemu, 135 00:13:41,899 --> 00:13:49,920 but we run a minimized so-called tender, which is this solo5-hvt monitor process. 136 00:13:49,920 --> 00:13:55,149 So that's something which just tries to allocate or will allocate some host system 137 00:13:55,149 --> 00:14:01,579 resources for the virtual machine and then does interaction with the virtual machine. 138 00:14:01,579 --> 00:14:06,989 So what does this solo5-hvt do in this case is to set up the memory, load the 139 00:14:06,989 --> 00:14:12,309 unikernel image which is a statically linked ELF binary and it sets up the 140 00:14:12,309 --> 00:14:17,829 virtual CPU. So the CPU needs some initialization and then booting is jumped 141 00:14:17,829 --> 00:14:24,740 to an address. It's already in 64 bit mode. There's no need to boot via 16 or 32 bit 142 00:14:24,740 --> 00:14:34,079 modes. Now solo5-hvt and the MirageOS they also have an interface and the interface 143 00:14:34,079 --> 00:14:38,819 is called hyper calls and that interface is rather small. So it only contains in 144 00:14:38,819 --> 00:14:46,019 total 14 different functions. Which main function yields a way to get the argument 145 00:14:46,019 --> 00:14:52,850 vector clock. Actually, two clocks, one is a POSIX clock, which takes care of this 146 00:14:52,850 --> 00:14:58,339 whole time stamping and timezone business and another one in a monotonic clock which 147 00:14:58,339 --> 00:15:06,569 by its name guarantees that time will pass monotonically. Then the other console 148 00:15:06,569 --> 00:15:12,510 interface. The console interface is only one way. So we only output data. We never 149 00:15:12,510 --> 00:15:18,149 read from console. A block device. Well a block devices and network interfaces and 150 00:15:18,149 --> 00:15:25,829 that's all the hyper calls we have. To look a bit further down into detail of how 151 00:15:25,829 --> 00:15:34,709 a MirageOS unikernel looks like. Here I pictured on the left again the tender at 152 00:15:34,709 --> 00:15:41,269 the bottom, and then the hyper calls. And then in pink I have the pieces of code 153 00:15:41,269 --> 00:15:46,939 which still contain some C code and the MirageOS unikernel. And in green I have 154 00:15:46,939 --> 00:15:55,140 the pieces of code which does not include any C code, but only OCaml code. So 155 00:15:55,140 --> 00:16:00,429 looking at the C code which is dangerous because in C we have to deal with memory 156 00:16:00,429 --> 00:16:05,749 management on our own, which means it's a bit brittle. We need to carefully review 157 00:16:05,749 --> 00:16:10,790 that code. It is definitely the OCaml runtime which we have here, which is round 158 00:16:10,790 --> 00:16:18,579 25 thousand lines of code. Then we have a library which is called nolibc which is 159 00:16:18,579 --> 00:16:24,339 basically a C library which implements malloc and string compare and some 160 00:16:24,339 --> 00:16:29,439 basic functions which are needed by the OCaml runtime. That's roughly 8000 lines 161 00:16:29,439 --> 00:16:37,060 of code. That nolibc also provides a lot of stops which just exit to or return 162 00:16:37,060 --> 00:16:46,850 null for the OCaml runtime because we use an unmodified OCaml runtime to be able to 163 00:16:46,850 --> 00:16:50,749 upgrade our software more easily. We don't have any patents for The OCaml runtime. 164 00:16:50,749 --> 00:16:57,419 Then we have a library called solo5-bindings, which is basically 165 00:16:57,419 --> 00:17:03,220 something which translates into hyper calls or which can access a hyper calls 166 00:17:03,220 --> 00:17:07,849 and which communicates with the host system via hyper calls. That is roughly 167 00:17:07,849 --> 00:17:14,910 2000 lines of code. Then we have a math library for sinus and cosinus and tangents 168 00:17:14,910 --> 00:17:20,940 and so on. And that is just the openlibm which is originally from the freeBSD 169 00:17:20,940 --> 00:17:26,980 project and has roughly 20000 lines of code. So that's it. So I talked a bit 170 00:17:26,980 --> 00:17:32,270 about solo5, about the bottom layer and I will go a bit more into detail about the 171 00:17:32,270 --> 00:17:40,120 solo5 stuff, which is really the stuff which you run at the bottom 172 00:17:40,120 --> 00:17:46,140 of the MirageOS. There's another choice. You can also run Xen or Qubes OS at 173 00:17:46,140 --> 00:17:50,870 the bottom of the MirageOS unikernel. But I'm focusing here mainly on solo5. So 174 00:17:50,870 --> 00:17:56,850 solo5 has a sandbox execution environment for unikernels. It handles resources from 175 00:17:56,850 --> 00:18:03,910 the host system, but only aesthetically. So you say at startup time how much memory 176 00:18:03,910 --> 00:18:09,150 it will take. How many network interfaces and which ones are taken and how many 177 00:18:09,150 --> 00:18:13,520 block devices and which ones are taken by the virtual machine. You don't have any 178 00:18:13,520 --> 00:18:19,430 dynamic resource management, so you can't add at a later point in time a new network 179 00:18:19,430 --> 00:18:28,040 interface. That's just not supported. And it makes the code much easier. We don't even 180 00:18:28,040 --> 00:18:36,360 have dynamic allocation inside of solo5. We have a hyper cool interface. As I 181 00:18:36,360 --> 00:18:42,330 mentioned, it's only 14 functions. We have bindings for different targets. So we can 182 00:18:42,330 --> 00:18:49,640 run on KVM, which is hypervisor developed for the Linux project, but also for 183 00:18:49,640 --> 00:18:57,060 Beehive, which is a free BSD hypervisor or VMM which is openBSD hypervisor. We also 184 00:18:57,060 --> 00:19:01,920 target other systems such as the g-node, wich is an operating system, based on a 185 00:19:01,920 --> 00:19:08,830 micro kernel written mainly in C++, virtio, which is a protocol usually spoken 186 00:19:08,830 --> 00:19:15,490 between the host system and the guest system, and virtio is used in a lot of 187 00:19:15,490 --> 00:19:22,770 cloud deployments. So it's OK. So qemu for example, provides you with a virtio 188 00:19:22,770 --> 00:19:29,430 protocol implementation. And a last implementation of solo5 or bindings for 189 00:19:29,430 --> 00:19:38,570 solo5 is seccomb. So Linux seccomb is a filter in the Linux kernel where you can 190 00:19:38,570 --> 00:19:47,180 restrict your process that will only use a certain number or a certain amount of 191 00:19:47,180 --> 00:19:53,790 system calls and we use seccomb so you can deploy it without virtual machine in the 192 00:19:53,790 --> 00:20:02,270 second case, but you are restricted to which system calls you can use. So solo5 193 00:20:02,270 --> 00:20:06,500 also provides you with the host system tender where applicable. So in the virtio 194 00:20:06,500 --> 00:20:11,880 case it not applicable. In the g-note case it is also not applicable. In KVM we 195 00:20:11,880 --> 00:20:19,220 already saw the solo5 HVT, wich is a hardware virtualized tender. Which is just 196 00:20:19,220 --> 00:20:25,790 a small binary because if you run qemu at least hundreds of thousands of lines of 197 00:20:25,790 --> 00:20:36,170 code in the solo5 HVT case, it's more like thousands of lines of code. So here we 198 00:20:36,170 --> 00:20:42,930 have a comparison from left to right of solo5 and how the host system or the host 199 00:20:42,930 --> 00:20:49,100 system kernel and the guest system works. In the middle we have a virtual machine, a 200 00:20:49,100 --> 00:20:54,490 common Linux qemu KVM based virtual machine for example, and on the right hand 201 00:20:54,490 --> 00:20:59,970 we have the host system and the container. Container is also a technology where you 202 00:20:59,970 --> 00:21:08,480 try to restrict as much access as you can from process. So it is contained and the 203 00:21:08,480 --> 00:21:14,940 potential compromise is also very isolated and contained. On the left hand side we 204 00:21:14,940 --> 00:21:21,270 see that solo5 is basically some bits and pieces in the host system. So is the solo5 205 00:21:21,270 --> 00:21:27,380 HVT and then some bits and pieces in Unikernel. So is the solo5 findings I 206 00:21:27,380 --> 00:21:31,200 mentioned earlier. And that is to communicate between the host and the guest 207 00:21:31,200 --> 00:21:37,100 system. In the middle we see that the API between the host system and the virtual 208 00:21:37,100 --> 00:21:41,310 machine. It's much bigger than this. And commonly using virtio and virtio is really 209 00:21:41,310 --> 00:21:48,920 a huge protocol which does feature negotiation and all sorts of things where 210 00:21:48,920 --> 00:21:54,010 you can always do something wrong, like you can do something wrong and a floppy 211 00:21:54,010 --> 00:21:58,650 disk driver. And that led to some exploitable vulnerability, although 212 00:21:58,650 --> 00:22:04,480 nowadays most operating systems don't really need a floppy disk drive anymore. 213 00:22:04,480 --> 00:22:08,180 And on the right hand side, you can see that the whole system interface for a 214 00:22:08,180 --> 00:22:12,530 container is much bigger than for a virtual machine because the whole system 215 00:22:12,530 --> 00:22:17,620 interface for a container is exactly those system calls you saw earlier. So it's run 216 00:22:17,620 --> 00:22:24,150 600 different calls. And in order to evaluate the security, you need basically 217 00:22:24,150 --> 00:22:32,770 to audit all of them. So that's just a brief comparison between those. If we look 218 00:22:32,770 --> 00:22:38,020 into more detail, what solo5 what shapes it can have here on the left side. We can 219 00:22:38,020 --> 00:22:43,350 see it running in a hardware virtualized tender, which is you have the Linux 220 00:22:43,350 --> 00:22:50,290 freebies, your openBSD at the bottom and you have solo5 blob, which is a blue thing 221 00:22:50,290 --> 00:22:54,590 here in the middle. And then on top you have the unikernel. On the right hand side 222 00:22:54,590 --> 00:23:02,850 you can see the Linux satcom process and you have a much smaller solo5 blob because 223 00:23:02,850 --> 00:23:06,940 it doesn't need to do that much anymore, because all the hyper calls are basically 224 00:23:06,940 --> 00:23:11,960 translated to system calls. So you actually get rid of them and you don't 225 00:23:11,960 --> 00:23:16,820 need to communicate between the host and the guest system because in seccomb you 226 00:23:16,820 --> 00:23:22,610 run as a whole system process so you don't have this virtualization. The advantage of 227 00:23:22,610 --> 00:23:29,220 using seccomb as well, but you can deploy it without having access to virtualization 228 00:23:29,220 --> 00:23:38,050 features of the CPU. Now to get it in even smaller shape. There's another backend I 229 00:23:38,050 --> 00:23:42,870 haven't talked to you about. It's called the Muen. It's a separation kernel 230 00:23:42,870 --> 00:23:50,870 developed in Ada. So you basically ... so now we try to get rid of this huge Unix 231 00:23:50,870 --> 00:23:58,320 system below it. Which is this big kernel thingy here. And Muen is an open source 232 00:23:58,320 --> 00:24:03,310 project developed in Switzerland in Ada, as I mentioned, and that uses SPARK, which 233 00:24:03,310 --> 00:24:12,620 is proof system, which guarantees the memory isolation between the different 234 00:24:12,620 --> 00:24:19,570 components. And Muen now goes a step further and it says, "Oh yeah. For you as 235 00:24:19,570 --> 00:24:23,540 a guest system, you don't do static allocations and you don't do dynamic 236 00:24:23,540 --> 00:24:28,210 resource management." We as a host system, we as a hypervisor, we don't do any 237 00:24:28,210 --> 00:24:34,350 dynamic resource allocation as well. So it only does static resource management. So 238 00:24:34,350 --> 00:24:39,250 at compile time of your Muen separation kernel you decide how many virtual 239 00:24:39,250 --> 00:24:44,460 machines or how many unikernels you are running and which resources are given to 240 00:24:44,460 --> 00:24:50,120 them. You even specify which communication channels are there. So if one of your 241 00:24:50,120 --> 00:24:55,560 virtual machines needs to talk to another one, you need to specify that at 242 00:24:55,560 --> 00:25:00,970 compile time and at runtime you don't have any dynamic resource management. So that 243 00:25:00,970 --> 00:25:08,620 again makes the code much easier, much, much less complex. And you get to much 244 00:25:08,620 --> 00:25:19,060 fewer lines of code. So to conclude with this Mirage and how this and also the Muen 245 00:25:19,060 --> 00:25:26,370 and solo5. And how that is. I like to cite Antoine: "Perfection is achieved, not when 246 00:25:26,370 --> 00:25:31,660 there is nothing more to add, but when there is nothing left to take away." I 247 00:25:31,660 --> 00:25:36,621 mean obviously the most secure system is a system which doesn't exist. 248 00:25:36,621 --> 00:25:40,210 *Laughter* 249 00:25:40,210 --> 00:25:41,638 Let's look a bit further 250 00:25:41,638 --> 00:25:46,440 into the decisions of MirageOS. Why do you use this strange 251 00:25:46,440 --> 00:25:50,960 programming language called OCaml and what's it all about? And what are the case 252 00:25:50,960 --> 00:25:59,170 studies? So OCaml has been around since more than 20 years. It's a multi paradigm 253 00:25:59,170 --> 00:26:05,890 programming language. The goal for us and for OCaml is usually to have declarative 254 00:26:05,890 --> 00:26:14,390 code. To achieve declarative code you need to provide the developers with some 255 00:26:14,390 --> 00:26:21,200 orthogonal abstraction facilities such as here we have variables then functions you 256 00:26:21,200 --> 00:26:24,890 likely know if you're a software developer. Also higher order functions. So 257 00:26:24,890 --> 00:26:31,500 that just means that the function is able to take a function as input. Then in OCaml 258 00:26:31,500 --> 00:26:37,270 we tried to always focus on the problem and do not distract with boilerplate. So 259 00:26:37,270 --> 00:26:43,510 some running example again would be this memory management. We don't manually deal 260 00:26:43,510 --> 00:26:52,940 with that, but we have computers to actually deal with that. In OCaml you have 261 00:26:52,940 --> 00:27:00,170 a very expressive and static type system, which can spot a lot of invariance or 262 00:27:00,170 --> 00:27:07,160 violation of invariance at build time. So the program won't compile if you don't 263 00:27:07,160 --> 00:27:14,196 handle all the potential return types or return values of your function. So now a 264 00:27:14,196 --> 00:27:20,190 type system, you know, you may know it from Java is a bit painful. If you have to 265 00:27:20,190 --> 00:27:24,250 express at every location where you want to have a variable, which type this 266 00:27:24,250 --> 00:27:31,900 variable is. What OCaml provides is type inference similar to Scala and other 267 00:27:31,900 --> 00:27:37,830 languages. So you don't need to type all the types manually. And types are also 268 00:27:37,830 --> 00:27:43,670 unlike in Java. Types are erased during compilation. So types are only information 269 00:27:43,670 --> 00:27:48,820 about values the compiler has at compile time. But at runtime these are all erased 270 00:27:48,820 --> 00:27:54,920 so they don't exist. You don't see them. And OCaml compiles to native machine code, 271 00:27:54,920 --> 00:28:01,580 which I think is important for security and performance. Because otherwise you run 272 00:28:01,580 --> 00:28:07,470 an interpreter or an abstract machine and you have to emulate something else and 273 00:28:07,470 --> 00:28:14,890 that is never as fast as you can. OCaml has one distinct feature, which is its 274 00:28:14,890 --> 00:28:21,460 module system. So you have all your values, which types or functions. And now 275 00:28:21,460 --> 00:28:26,840 each of those values is defined inside of a so-called module. And the simplest 276 00:28:26,840 --> 00:28:32,670 module is just the filename. But you can nest modules so you can explicitly say, oh 277 00:28:32,670 --> 00:28:39,540 yeah, this value or this binding is now living in a sub module here off. So each 278 00:28:39,540 --> 00:28:45,260 module you can also give it a type. So it has a set of types and a set of functions 279 00:28:45,260 --> 00:28:52,600 and that is called its signature, which is the interface of the module. Now you have 280 00:28:52,600 --> 00:28:59,600 another abstraction mechanism in OCaml which is functors. And functors are 281 00:28:59,600 --> 00:29:04,470 basically compile time functions from module to module. So they allow a 282 00:29:04,470 --> 00:29:09,990 pyramidisation. Like you can implement your generic map structure and all you 283 00:29:09,990 --> 00:29:18,740 require. So map is just a hash map or a implementation is maybe a binary tree. And 284 00:29:18,740 --> 00:29:25,980 you need to have is some comparison for the keys and that is modeled in OCaml by 285 00:29:25,980 --> 00:29:32,427 module. So you have a module called map and you have a functor called make. And the 286 00:29:32,427 --> 00:29:38,460 make takes some module which implements this comparison method and then provides 287 00:29:38,460 --> 00:29:45,740 you with map data structure for that key type. And then MirageOS we actually use a 288 00:29:45,740 --> 00:29:51,800 module system quite a bit more because we have all these resources which are 289 00:29:51,800 --> 00:29:58,330 different between Xen and KVM and so on. So each of the different resources like a 290 00:29:58,330 --> 00:30:06,740 network interface has a signature. OK, and target specific implementation. So we have 291 00:30:06,740 --> 00:30:11,210 the TCP/IP stack, which is much higher than the network card, but it doesn't 292 00:30:11,210 --> 00:30:16,920 really care if you run on Xen or if you run on KVM. You just program against this 293 00:30:16,920 --> 00:30:22,270 abstract interface against the interface of the network device. But you don't need 294 00:30:22,270 --> 00:30:27,740 to program. You don't need to write in your TCP/IP stack any code to run on Xen 295 00:30:27,740 --> 00:30:38,230 or to run on KVM. So MirageOS also doesn't really use the complete OCaml 296 00:30:38,230 --> 00:30:44,410 programming language. OCaml also provides you with an object system and we barely 297 00:30:44,410 --> 00:30:49,720 use that. We also have in MirageOS... well OCaml also allows you for with mutable 298 00:30:49,720 --> 00:30:57,610 state. And we barely used that mutable state, but we use mostly immutable data 299 00:30:57,610 --> 00:31:05,429 whenever sensible. We also have a value passing style, so we put state and data as 300 00:31:05,429 --> 00:31:12,000 inputs. So stage is just some abstract state and data is just a byte vector 301 00:31:12,000 --> 00:31:17,010 in a protocol implementation. And then the output is also a new state which may be 302 00:31:17,010 --> 00:31:22,179 modified and some reply maybe so some other byte vector or some application 303 00:31:22,179 --> 00:31:31,790 data. Or the output data may as well be an error because the incoming data and state 304 00:31:31,790 --> 00:31:38,179 may be invalid or might maybe violate some some constraints. And errors are also 305 00:31:38,179 --> 00:31:44,110 explicitly types, so they are declared in the API and the call of a function needs 306 00:31:44,110 --> 00:31:52,480 to handle all these errors explicitly. As I said, the single core, but we have some 307 00:31:52,480 --> 00:32:00,690 promise based or some even based concurrent programming stuff. And yeah, we 308 00:32:00,690 --> 00:32:04,450 have the ability to express a really strong and variants like this is a read- 309 00:32:04,450 --> 00:32:08,340 only buffer in the type system. And the type system is, as I mentioned, only 310 00:32:08,340 --> 00:32:15,161 compile time, no runtime overhead. So it's all pretty nice and good. So let's take a 311 00:32:15,161 --> 00:32:21,210 look at some of the case studies. The first one is unikernel. So it's called the 312 00:32:21,210 --> 00:32:29,740 Bitcoin Pinata. It started in 2015 when we were happy with from the scratch developed 313 00:32:29,740 --> 00:32:35,100 TLS stack. TLS is transport layer security. So what use if you browse to 314 00:32:35,100 --> 00:32:41,720 HTTPS. So we have an TLS stack in OCaml and we wanted to do some marketing for 315 00:32:41,720 --> 00:32:50,670 that. Bitcoin Pinata is basically unikernel which uses TLS and provides you 316 00:32:50,670 --> 00:32:57,790 with TLS endpoints, and it contains the private key for a bitcoin wallet which is 317 00:32:57,790 --> 00:33:05,790 filled with, which used to be filled with 10 bitcoins. And this means it's a 318 00:33:05,790 --> 00:33:10,770 security bait. So if you can compromise the system itself, you get the private key 319 00:33:10,770 --> 00:33:16,420 and you can do whatever you want with it. And being on this bitcoin block chain, it 320 00:33:16,420 --> 00:33:22,880 also means it's transparent so everyone can see that that has been hacked or not. 321 00:33:22,880 --> 00:33:30,450 Yeah and it has been online since three years and it was not hacked. But the bitcoin we 322 00:33:30,450 --> 00:33:35,630 got were only borrowed from friends of us and they were then reused in other 323 00:33:35,630 --> 00:33:40,370 projects. It's still online. And you can see here on the right that we had some 324 00:33:40,370 --> 00:33:49,740 HTTP traffic, like an aggregate of maybe 600,000 hits there. Now I have a size 325 00:33:49,740 --> 00:33:54,600 comparison of the Bitcoin Pinata on the left. You can see the unikernel, which is 326 00:33:54,600 --> 00:34:00,410 less than 10 megabytes in size or in source code it's maybe a hundred thousand 327 00:34:00,410 --> 00:34:06,000 lines of code. On the right hand side you have a very similar thing, but running as 328 00:34:06,000 --> 00:34:16,489 a Linux service so it runs an openSSL S server, which is a minimal TLS server you 329 00:34:16,489 --> 00:34:22,820 can get basically on a Linux system using openSSL. And there we have mainly maybe a 330 00:34:22,820 --> 00:34:29,019 size of 200 megabytes and maybe two million two lines of code. So that's 331 00:34:29,019 --> 00:34:36,409 roughly a vector of 25. In other examples, we even got a bit less code, much bigger 332 00:34:36,409 --> 00:34:45,310 effect. Performance analysis I showed that ... Well, in 2015 we did some evaluation 333 00:34:45,310 --> 00:34:50,659 of our TLS stack and it turns out we're in the same ballpark as other 334 00:34:50,659 --> 00:34:56,769 implementations. Another case study is CalDAV server, which we developed last 335 00:34:56,769 --> 00:35:04,729 year with a grant from Prototypefund which is a German government funding. It is 336 00:35:04,729 --> 00:35:09,279 intolerable with other clients. It stores data in a remote git repository. So we 337 00:35:09,279 --> 00:35:14,140 don't use any block device or persistent storage, but we store it in a git 338 00:35:14,140 --> 00:35:18,599 repository so whenever you add the calendar event, it does actually a git 339 00:35:18,599 --> 00:35:24,829 push. And we also recently got some integration with CalDAV web, which is a 340 00:35:24,829 --> 00:35:30,980 JavaScript user interface doing in JavaScript, doing a user interface. And we 341 00:35:30,980 --> 00:35:36,940 just bundle that with the thing. It's online, open source, there is a demo 342 00:35:36,940 --> 00:35:42,440 server and the data repository online. Yes, some statistics and I zoom in 343 00:35:42,440 --> 00:35:47,970 directly to the CPU usage. So we had the luck that we for half of a month, we used 344 00:35:47,970 --> 00:35:56,170 it as a process on a freeBSD system. And that happened roughly the first half until 345 00:35:56,170 --> 00:36:01,420 here. And then at some point we thought, oh, yeah, let's migrated it to MirageOS 346 00:36:01,420 --> 00:36:06,329 unikernel and don't run the freeBSD system below it. And you can see here on the x 347 00:36:06,329 --> 00:36:11,460 axis the time. So that was the month of June, starting with the first of June on 348 00:36:11,460 --> 00:36:16,950 the left and the last of June on the right. And on the y axis, you have the 349 00:36:16,950 --> 00:36:22,829 number of CPU seconds here on the left or the number of CPU ticks here on the right. 350 00:36:22,829 --> 00:36:28,650 The CPU ticks are virtual CPU ticks which debug counters from the hypervisor. 351 00:36:28,650 --> 00:36:33,430 So from beehive and freeBSD here in that system. And what you can see here is this 352 00:36:33,430 --> 00:36:39,460 massive drop by a factor of roughly 10. And that is when we switched from a Unix 353 00:36:39,460 --> 00:36:46,040 virtual machine with the process to a freestanding Unikernel. So we actually use 354 00:36:46,040 --> 00:36:50,910 much less resources. And if we look into the bigger picture here, we also see that 355 00:36:50,910 --> 00:36:57,710 the memory dropped by a factor of 10 or even more. This is now a logarithmic scale 356 00:36:57,710 --> 00:37:03,039 here on the y axis, the network bandwidth increased quite a bit because now we do 357 00:37:03,039 --> 00:37:09,549 all the monitoring traffic, also via net interface and so on. Okay, that's CalDAV. 358 00:37:09,549 --> 00:37:16,759 Another case study is authoritative DNS servers. And I just recently wrote a 359 00:37:16,759 --> 00:37:22,329 tutorial on that. Which I will skip because I'm a bit short on time. Another 360 00:37:22,329 --> 00:37:27,210 case study is a firewall for QubesOS. QubesOS is a reasonable, secure operating 361 00:37:27,210 --> 00:37:33,390 system which uses Xen for isolation of workspaces and applications such as PDF 362 00:37:33,390 --> 00:37:38,609 reader. So whenever you receive a PDF, you start your virtual machine, which is only 363 00:37:38,609 --> 00:37:48,160 run once and you, well which is just run to open and read your PDF. And Qubes Mirage 364 00:37:48,160 --> 00:37:54,039 firewall is now small or a tiny replacement for the Linux based firewall 365 00:37:54,039 --> 00:38:02,160 written in OCaml now. And instead of roughly 300mb, you only use 32mb 366 00:38:02,160 --> 00:38:09,259 of memory. There's now also recently some support for dynamic firewall rules 367 00:38:09,259 --> 00:38:16,760 as defined by Qubes 4.0. And that is not yet merged into master, but it's under 368 00:38:16,760 --> 00:38:23,480 review. Libraries in MirageOS yeah we have since we write everything from scratch and 369 00:38:23,480 --> 00:38:29,750 in OCaml we don't have now. We don't have every protocol, but we have quite a few 370 00:38:29,750 --> 00:38:35,280 protocols. There are also more unikernels right now, which you can see here in the 371 00:38:35,280 --> 00:38:41,849 slides. Also online in the Fahrplan so you can click on the links later. Repeaters 372 00:38:41,849 --> 00:38:47,509 were built. So for security purposes we don't get shipped binaries. But I plan to 373 00:38:47,509 --> 00:38:51,540 ship binaries and in order to ship binaries. I don't want to ship non 374 00:38:51,540 --> 00:38:56,549 reputable binaries. What is reproducible builds? Well it means that if you have the 375 00:38:56,549 --> 00:39:05,960 same source code, you should get the binary identical output. And issues are 376 00:39:05,960 --> 00:39:14,640 temporary filenames and timestamps and so on. In December we managed in MirageOS to 377 00:39:14,640 --> 00:39:21,270 get some tooling on track to actually test the reproducibility of unikernels and we 378 00:39:21,270 --> 00:39:27,839 fixed some issues and now all the tests in MirageOS unikernels reporducable, which 379 00:39:27,839 --> 00:39:34,009 are basically most of them from this list. Another topic, a supply chain security, 380 00:39:34,009 --> 00:39:42,210 which is important, I think, and we have this is still a work in progress. We still 381 00:39:42,210 --> 00:39:48,859 haven't deployed that widely. But there are some test repositories out there to 382 00:39:48,859 --> 00:39:56,869 provide more, to provide signatures signed by the actual authors of a library and 383 00:39:56,869 --> 00:40:02,670 getting you across until the use of the library can verify that. And some 384 00:40:02,670 --> 00:40:09,390 decentralized authorization and delegation of that. What about deployment? Well, in 385 00:40:09,390 --> 00:40:15,999 conventional orchestration systems such as Kubernetes and so on. We don't yet have 386 00:40:15,999 --> 00:40:24,220 a proper integration of MirageOS, but we would like to get some proper integration 387 00:40:24,220 --> 00:40:31,700 there. If you already generate some libvirt.xml files from Mirage. So for each 388 00:40:31,700 --> 00:40:37,690 unikernel you get the libvirt.xml and you can do that and run that in your libvirt 389 00:40:37,690 --> 00:40:44,529 based orchestration system. For Xen, we also generate those .xl and .xe files, 390 00:40:44,529 --> 00:40:49,500 which I personally don't really know much about, but that's it. On the 391 00:40:49,500 --> 00:40:56,289 other side, I developed an orchestration system called Albatross because I was a 392 00:40:56,289 --> 00:41:02,529 bit worried if I now have those tiny unikernels which are megabytes in size 393 00:41:02,529 --> 00:41:09,089 and now I should trust the big Kubernetes, which is maybe a million lines of code 394 00:41:09,089 --> 00:41:15,730 running on the host system with privileges. So I thought, oh well let's 395 00:41:15,730 --> 00:41:21,339 try to come up with a minimal orchestration system which allows me some 396 00:41:21,339 --> 00:41:26,630 console access. So I want to see the debug messages or whenever it fails to boot I 397 00:41:26,630 --> 00:41:32,099 want to see the output of the console. Want to get some metrics like the Graphana 398 00:41:32,099 --> 00:41:38,930 screenshot you just saw. And that's basically it. Then since I developed also 399 00:41:38,930 --> 00:41:45,329 a TLS stack, I thought, oh yeah, well why not just use it for remote deployment? So 400 00:41:45,329 --> 00:41:51,499 in TLS you have mutual authentication, you can have client certificates and 401 00:41:51,499 --> 00:41:57,460 certificate itself is more or less an authenticated key value store because you 402 00:41:57,460 --> 00:42:03,859 have those extensions and X 509 version 3 and you can put arbitrary data in there 403 00:42:03,859 --> 00:42:09,190 with keys being so-called object identifiers and values being whatever 404 00:42:09,190 --> 00:42:16,539 else. TLS certificates have this great advantage that or X 509 certificates have 405 00:42:16,539 --> 00:42:23,550 the advantage that during a TLS handshake they are transferred on the wire in not 406 00:42:23,550 --> 00:42:33,950 base64 or PEM encoding as you usually see them, but in basic encoding which is much 407 00:42:33,950 --> 00:42:41,049 nicer to the amount of bits you transfer. So it's not transferred in base64, but 408 00:42:41,049 --> 00:42:45,820 directly in raw basically. And with Alabtross you can basically do a TLS 409 00:42:45,820 --> 00:42:50,769 handshake and in that client certificate you present, you already have the 410 00:42:50,769 --> 00:42:58,359 unikernel image and the name and the boot arguments and you just deploy it directly. 411 00:42:58,359 --> 00:43:04,229 You can alter an X 509. You have a chain of certificate authorities, which you send 412 00:43:04,229 --> 00:43:09,150 with and this chain of certificate authorities also contain some extensions 413 00:43:09,150 --> 00:43:14,720 in order to specify which policies are active. So how many virtual machines are 414 00:43:14,720 --> 00:43:21,599 you able to deploy on my system? How much memory you you have access to and which 415 00:43:21,599 --> 00:43:26,930 bridges or which network interfaces you have access to? So Albatross is really a 416 00:43:26,930 --> 00:43:33,779 minimal orchestration system running as a family of Unix processes. It's maybe 3000 417 00:43:33,779 --> 00:43:41,319 lines of code or so. OCaml code. But using then the TLS stack and so on. But yeah, it 418 00:43:41,319 --> 00:43:46,630 seems to work pretty well. I at least use it for more than two dozen unikernels at 419 00:43:46,630 --> 00:43:52,191 any point in time. What about the community? Well the whole MirageOS project 420 00:43:52,191 --> 00:43:57,930 started around 2008 at University of Cambridge, so it used to be a research 421 00:43:57,930 --> 00:44:03,819 project with which still has a lot of ongoing student projects at University of 422 00:44:03,819 --> 00:44:10,559 Cambridge. But now it's an open source permissive license, mostly BSD licensed 423 00:44:10,559 --> 00:44:20,769 thing, where we have community event every half a year and a retreat in Morocco where 424 00:44:20,769 --> 00:44:25,819 we also use our own unikernels like the DHTP server and the DNS resolve and so on. 425 00:44:25,819 --> 00:44:31,700 We just use them to test them and to see how does it behave and does it work for 426 00:44:31,700 --> 00:44:40,170 us? We have quite a lot of open source computer contributors from all over and 427 00:44:40,170 --> 00:44:46,420 some of the MirageOS libraries have also been used or are still used in this Docker 428 00:44:46,420 --> 00:44:51,810 technology, Docker for Mac and Docker for Windows, which emulates the guest system 429 00:44:51,810 --> 00:45:02,089 or which needs some wrappers. And there is a lot of OCaml code is used. So to finish 430 00:45:02,089 --> 00:45:07,319 my talk, I would like to have another side, which is that Rome wasn't built in a 431 00:45:07,319 --> 00:45:14,920 day. So where we are is to conclude here we have a radical approach to operating 432 00:45:14,920 --> 00:45:22,089 systems development. We have a security from the ground up with much fewer code 433 00:45:22,089 --> 00:45:30,079 and we also have much fewer attack vectors because we use a memory safe 434 00:45:30,079 --> 00:45:39,079 language. So we have reduced the carbon footprint, as I mentioned in the start of 435 00:45:39,079 --> 00:45:45,619 the talk, because we use much less CPU time, but also much less memory. So we use 436 00:45:45,619 --> 00:45:53,190 less resources. MirageOS itself and O'Caml have a reasonable performance. We have 437 00:45:53,190 --> 00:45:56,979 seen some statistics about the TLS stack that it was in the same ballpark as 438 00:45:56,979 --> 00:46:05,519 OpenSSL and PolarSSL, which is nowadays MBed TLS, and MirageOS unikernels, since 439 00:46:05,519 --> 00:46:10,589 they don't really need to negotiate features and wait for the Scottie Pass and 440 00:46:10,589 --> 00:46:14,759 so on. They actually do it in milliseconds, not in seconds, so they do 441 00:46:14,759 --> 00:46:21,939 not hardware probing and so on. But they know that startup time what they expect. I 442 00:46:21,939 --> 00:46:27,489 would like to thank everybody who is and was involved in this whole technology 443 00:46:27,489 --> 00:46:32,769 stack because I myself I program quite a bit of O'Caml, but I wouldn't have been 444 00:46:32,769 --> 00:46:39,009 able to do that on my own. It is just a bit too big. MirageOS currently spends 445 00:46:39,009 --> 00:46:45,490 around maybe 200 different git repositories with the libraries, mostly 446 00:46:45,490 --> 00:46:52,500 developed on GitHub and open source. I am at the moment working in a nonprofit 447 00:46:52,500 --> 00:46:56,890 company in Germany, which is called the Center for the Cultivation of Technology 448 00:46:56,890 --> 00:47:02,650 with a project called robur. So we work in a collective way to develop full-stack 449 00:47:02,650 --> 00:47:08,030 MirageOS unikernels. That's why I'm happy to do that from Dublin. And if you're 450 00:47:08,030 --> 00:47:14,450 interested, please talk to us. I have some selected related talks, there are much 451 00:47:14,450 --> 00:47:20,869 more talks about MirageOS. But here is just a short list of something, if you're 452 00:47:20,869 --> 00:47:29,529 interested in some certain aspects, please help yourself to view them. 453 00:47:29,529 --> 00:47:31,761 That's all from me. 454 00:47:31,761 --> 00:47:37,380 *Applause* 455 00:47:37,380 --> 00:47:46,440 Herald: Thank you very much. There's a bit over 10 minutes of time for questions. If 456 00:47:46,440 --> 00:47:50,010 you have any questions go to the microphone. There's several microphones 457 00:47:50,010 --> 00:47:54,210 around the room. Go ahead. Question: Thank you very much for the talk 458 00:47:54,210 --> 00:47:57,210 - Herald: Writ of order. Thanking the 459 00:47:57,210 --> 00:48:01,109 speaker can be done afterwards. Questions are questions, so short sentences ending 460 00:48:01,109 --> 00:48:05,989 with a question mark. Sorry, do go ahead. Question: If I want to try this at home, 461 00:48:05,989 --> 00:48:08,989 what do I need? Is a raspi sufficient? No, it isn't. 462 00:48:08,989 --> 00:48:15,309 Hannes: That is an excellent question. So I usually develop it on such a thinkpad 463 00:48:15,309 --> 00:48:23,019 machine, but we actually support also ARM64 mode. So if you have a Raspberry Pi 464 00:48:23,019 --> 00:48:28,890 3+, which I think has the virtualization bits and the Linux kernel, which is reason 465 00:48:28,890 --> 00:48:35,249 enough to support KVM on that Raspberry Pi 3+, then you can try it out there. 466 00:48:35,249 --> 00:48:41,789 Herald: Next question. Question: Well, currently most MirageOS 467 00:48:41,789 --> 00:48:51,719 unikernels are used for running server applications. And so obviously this all 468 00:48:51,719 --> 00:48:58,230 static preconfiguration of OCaml and maybe Ada SPARK is fine for that. But what 469 00:48:58,230 --> 00:49:03,819 do you think about... Will it ever be possible to use the same approach with all 470 00:49:03,819 --> 00:49:10,009 this static reconfiguration for these very dynamic end user desktop systems, for 471 00:49:10,009 --> 00:49:15,220 example, like which at least currently use quite a lot of plug-and-play. 472 00:49:15,220 --> 00:49:19,430 Hannes: Do you have an example? What are you thinking about? 473 00:49:19,430 --> 00:49:26,410 Question: Well, I'm not that much into the topic of its SPARK stuff, but you said 474 00:49:26,410 --> 00:49:32,239 that all the communication's paths have to be defined in advance. So especially with 475 00:49:32,239 --> 00:49:37,779 plug-and-play devices like all this USB stuff, we either have to allow everything 476 00:49:37,779 --> 00:49:46,549 in advance or we may have to reboot parts of the unikernels in between to allow 477 00:49:46,549 --> 00:49:54,660 rerouting stuff. Hannes: Yes. Yes. So I mean if you want to 478 00:49:54,660 --> 00:50:01,119 design a USB plug-and-play system, you can think of it as you plug in somewhere the 479 00:50:01,119 --> 00:50:07,839 USB stick and then you start the unikernel which only has access to that USB stick. 480 00:50:07,839 --> 00:50:15,319 But having a unikernel... Well I wouldn't design a unikernel which randomly does 481 00:50:15,319 --> 00:50:23,569 plug and play with the the outer world, basically. So. And one of the applications 482 00:50:23,569 --> 00:50:30,800 I've listed here is at the top is a picture viewer, which is a unikernel that 483 00:50:30,800 --> 00:50:37,400 also at the moment, I think has static embedded data in it. But is able on Qubes 484 00:50:37,400 --> 00:50:43,819 OS or on Unix and SDL to display the images and you can think of some way we 485 00:50:43,819 --> 00:50:48,670 are a network or so to access the images actually. So you didn't need to compile 486 00:50:48,670 --> 00:50:54,380 the images in, but you can have a good repository or TCP server or whatever in 487 00:50:54,380 --> 00:51:01,079 order to receive the images. So I am saying. So what I didn't mention is that 488 00:51:01,079 --> 00:51:05,759 MirageOS instead of being general purpose and having a shell and you can do 489 00:51:05,759 --> 00:51:11,279 everything with it, it is that each service, each unikernel is a single 490 00:51:11,279 --> 00:51:16,529 service thing. So you can't do everything with it. And I think that is an advantage 491 00:51:16,529 --> 00:51:23,309 from a lot of points of view. I agree that if you have a highly dynamic system, 492 00:51:23,309 --> 00:51:27,680 that you may have some trouble on how to integrate that. 493 00:51:27,680 --> 00:51:38,679 Herald: Are there any other questions? No, it appears not. In which case, 494 00:51:38,679 --> 00:51:41,111 thank you again, Hannes. Warm applause for Hannes. 495 00:51:41,111 --> 00:51:44,529 *Applause* 496 00:51:44,529 --> 00:51:49,438 *Outro music* 497 00:51:49,438 --> 00:52:12,000 subtitles created by c3subtitles.de in the year 2020. Join, and help us!