:::warning Ce document est contributif. Pour l'éditer vous pouvez passer en mode édition : This document is contributory. To edit it you can switch to edit mode [**<i class="fa fa-edit fa-fw"></i>**](https://pad.public.cat/offdem-o2-index?edit)/[**<i class="fa fa-columns fa-fw"></i>**](https://pad.public.cat/offdem-o2-index?both) * Si vous n'êtes pas à l'aise avec la syntaxe markdown, ce [tutoriel](https://pad.numerique-en-commun.fr/utiliser-codimd?view) est à votre disposition. * If you are not comfortable with markdown syntax, this [tutorial](https://www.markdownguide.org/basic-syntax/) is for you. ::: # [OFFDEM O₂] Deploying MirageOS unikernels <center> ### <https://mirage.io/> </center>  <center> ## >>> [Retour au pad annuaire : Back to Index](https://pad.public.cat/offdem-o2-index) <<< </center> --- [TOC] --- :::success **Un petit mot d'ambiance :** Une présentation de l'approche de MirageOS. Une des tables rondes les plus techniques du OFFDEM O₂, mais qui a su détailler certains des choix techniques de MirageOS pour des non-initiés : impact carbone, sécurité... Bref, tout le monde pouvait repartir en ayant appris quelque chose de technique. ::: ## À propos de Mirage OS **[MirageOS](https://mirageos.org/)** est un système d'exploitation à bibliothèques - chaque service, également appelé unikernel, peut être exécuté comme une machine virtuelle séparée. Seules les bibliothèques nécessaires se retrouvent dans un unikernel - par exemple, un serveur DNS faisant autorité n'inclut pas de système de fichiers, de _shell_, de gestion des utilisateurs, ni de gestion des processus. ## A propos En général, le matériel se trouve en bas de l'échelle, et de là, la pile monte : les systèmes, puis l'utilisateur. Maintenant, les ordinateurs ont des hyperviseurs exécutés par la machine physique. Et vous exécutez vos logiciels dans des machines virtuelles. Beaucoup sont exécutées sur un seul ordinateur. Comme chaque couche utilise généralement ses propres planificateurs, un processus typique peut utiliser 3 planificateurs différents. Le code dont vous vous souciez ne représente qu'une petite fraction du code exécuté par le système d'exploitation. 70 % des CVE (Common Vulnerabilities and Exposure) sont basés sur la corruption de la mémoire. Les _exploits du jour zéro_[^0d] sont généralement de ce type. [^0d]: _Zero Day Exploit_ en anglais. Les _exploits_ sont des manières concrètes d'abuser de vulnérabilités dans le code pour prendre le contrôle effectif d'une machine. _Zero Day_ fait référence à la disponibilité des vulnérabilités : ici, qu'elles ont été découvertes par l'attaquant et ne sont pas encore diffusées. En général, le langage de programmation ne prend pas soin de la mémoire pour éviter/limiter la vulnérabilité de la mémoire (exemple : python, java, etc). Mais il existe d'autres langages comme OCaml (utilisé dans MirageOS) ou Rust qui sont conçus pour éviter les problèmes de mémoire. Cela permet de réduire les vecteurs d'attaque (sécurité de la mémoire). En outre, étant donné que le code produit ne concerne que la fonctionnalité, cela permet de réduire la surface d'attaque et la complexité (temps d'exécution, configuration) ; ainsi que l'empreinte carbone. * Chaque service est un noyau OS mirage séparé. * Tâche coopérative pour répondre à des demandes multiples * Réduction au minimum du code : pas de gestion des utilisateurs, pas de gestion des processus, etc. * Langage Ocaml avec gestion automatisée de la mémoire Hyperviseur [solo5-hvt](https://github.com/Solo5/solo5#about-solo5) personnalisé pour attribuer la mémoire/vCPU. Plus léger que Qemu/KVM.  *Lua est implémenté pour les scripts, Python pas encore. Solo5 est un environnement petit et _sandboxé_ pour unikernel, une interface _hypercall_ minuscule. (Les graphiques jaunes représentent solo5 par rapport aux autres approches). Cible de haute assurance, développée par quelqu'un en Suisse.  « Avez-vous quelque chose pour gérer la persistance ? » Oui, des blocs. (Demandez à nouveau) « Le graphique de droite montre une augmentation dans le temps, pourquoi ? » Il y a une explication : un développeur a quitté le projet et n'est pas pressé de réparer ses fuites de mémoire. Deuxième étude de cas (DNS) Troisième pare-feu QubesOS ## Déploiement Pour faciliter un déploiement minimaliste des unikernels, j'ai développé albatross. Un système d'orchestration minimal.  ## Monitoring avec Grafana  ## Communauté MirageOS  ## Dans le futur * Sécuriser la chaîne d'approvisionnement * Développer plus d'unikernels ## Questions > En ce qui concerne les problèmes de performances, comment avez-vous fait vos choix d'implémentations (c'est-à-dire `malloc` de base) ? Les problèmes de performance sont principalement dus à la complexité du code. (Demandez à nouveau ici) > Savez-vous si d'autres architectures comme mipsel ou ARM supportent OCaml ? Oui, nous avons le support ARM, le support ARM64 est là, le support 32 bits est presque là. (mipsel ?) mipsel, je ne pense pas. (Il serait intéressant que notre protocole de routage soit implémenté dans cet environnement, pour mieux contrôler les choses qui sont problématiques avec les protocoles de routage. Mais la plupart des routeurs de notre réseau sont mipsel. Nous avons essayé de passer à arm64 pour passer à rasberry pi 4 comme plateforme matérielle mais ce n'est pas disponible pour le moment avec la pénurie de puces donc le support de mipsel serait clé pour nous). Oui, et je peux dire que je ne pense pas qu'il y ait un support mipsel pour OCaml, et je ne serais pas en mesure de travailler dessus. (Savez-vous s'il y a des travaux dans ce sens ?) Je ne sais pas. --- # English Version :::success **A word about the atmosphere:** A presentation of the MirageOS approach. One of the most technical round tables of the OFFDEM O², but one that was able to detail some of the technical choices of MirageOS for the uninitiated: carbon impact, security... In short, everyone could leave having learned something technical. ::: ## About Mirage OS **[MirageOS](https://mirageos.org/)** 3 is a library operating system – each service, also called unikernel, can be run as a separate virtual machine[1]. Only the required libraries ends up in a unikernel – e.g. an authoritative DNS server does not include a file system, a shell, or user management, neither process management. ## About Usually you have hardware at the bottom, and from there the stack goes up : systems, then the user. Now computers have hypervisors run by the physical machine. And your run your software in Virtual machines. Many are run on a single computer. As each layer typically use their own schedulers, a typical process can use 3 different schedulers. The code you care about is just a small fraction of the code the OS run. 70 % of the CVE (Common Vulnerabilities and Exposure) are based on memory corruption. Zero days exploits are typically of this type. Language are not taking care of memory to avoid/limits memory vulnerability (example: python, java, etc). * Reducing attack vectors (memory safety) * Reducing attack surface * Reducing complexity (run-time, configuration) * Reducing carbon footprint * Each service is a separate mirage os kernel * Cooperative task to reply to multiple requests * Reduction at the minimum of the code no user management no process management etc * Ocaml language with automated memory management Custom solo5hvt hypervisor to attribute memory/vcpu. Lighter than qemu/kvm.  * lua is implemented for scripting, python not yet. SOlo5 is small and sandboxed environment for unikernel, tiny hypercall interface (Yellow graphs represent solo5 compared to other approaches) High assurance target, developed by someone in Switzerland.  "Do you have anything to manage persistence ?" Yes, blocks. (Ask again) "The right hand graph shows an increase over time, why ?" There's an explanation : a developper left the project and isn't eager to fix his memory leaks. Second case study (DNS) Third QubesOS firewall ## Deployment To facilitate a minimalmist deployment of unikernels, I developped albatross. A minimal orchestration system.  ## Monitoring with Grafana  ## MirageOS community  ## In the future * Secure the supply chain * Develop more unikernels ## Questions > Regarding performances issues, how did you make your choices of implementations (ie basic malloc) ? The performance issues are mainly due to code complexity. (Ask again here) > Do you know about other architectures like mipsel or ARM support for OCaml? Yes, we have ARM support, ARM64 support is there, 32-bit support is nearly there. (mipsel?) mipsel, I think not. (It would be interesting for our routing protocol to be implemented in this environment, to control better, things which are problematic with routing protocols. But most of the routers in our network are mipsel. We tried to switch to arm64 to move to rasberry pi 4 as a hardware platform but it's not available at the moment with the chips shortage so mipsel support would be key for us.) Yeah, and I can say that I don't think there's mipsel support for OCaml, and I wouldn't be able to work on that. (Do you know if there's any work in that direction?) I don't know. --- <center> ## >>> [Retour au pad annuaire : Back to Index](https://pad.public.cat/offdem-o2-index) <<< </center> --- <center> :::danger Ce document est régi par la [Licence Art Libre 1.3 (LAL 1.3)](https://artlibre.org/) par les participant⋅e⋅s OFFDEM O₂ 2022 This document is governed by the [Free Art License 1.3 (FAL 1.3)](https://artlibre.org/) By OFFDEM O₂ 2022 attendees ::: </center>