 la première fois que j'ai rencontré notre prochaine conférencier c'était il ya une douzaine d'années à une conférence à berlin dont je donnerai pas le nom où il nous a présenté du hacking de voiture avant qu'on parle de hacking de voiture où il injectait du trafic qui permettait de rerouter les systèmes de navigation heureusement il a arrêté de casser des voitures mais maintenant il construit des systèmes sécurisés et il y en a peut-être un l'armory usb et pour ça il a dû développer tamago qui est un run time go bas niveau pour des soc arrm et dont vient parler aujourd'hui applaudissez s'il vous plaît andrea barisani vous m'entendez ok ok merci pour l'intro merci de m'avoir appelé à quel point je suis vieux maintenant et bon on casse toujours des voitures mais maintenant c'est juste du boulot c'est plus c'est plus un hobby la partie hobby c'est ce dont je vais parler maintenant alors je travaille pour fc cure petit mot de présentation pour moi donc je travaille chez fc cure vous me connaissez peut-être pour une entreprise que j'ai créé qui s'appelle inverse pass qui a été acheté par fc cure il y a quelques années je suis une des personnes qui développe la usb armory et comme ça a été dit dans l'introduction je travaille beaucoup avec le hardware et des systèmes où la sécurité critique comme par exemple des avions des voitures etc et parce que je vieillis j'ai tendance à vouloir construire des choses plutôt que juste casser des choses et je pense que c'est quelque chose d'inevitable dans la vie d'un chercheur en sécurité vous vieillissez vous fatiguez un peu vous s'envez marre de juste montrer ça s'est cassé ça s'est cassé ça s'est cassé et au bout d'un moment l'industrie devient tellement douée en matière de casser des choses que on se dit faut peut-être s'arrêter et penser autrement et se mettre à créer des choses des logiciels du matériel qui va peut-être aider la communauté de la sécurité à résoudre des problèmes parce que on voit qu'il y a beaucoup de problèmes qui ne changent jamais alors que on est presque en 2020 et une des raisons pour lesquelles nous on crée du hardware libre notamment l'usb armory et tamago qui est très très nécessaire à l'usb armory comme on va voir c'est de pouvoir créer des outils en qui on peut avoir confiance des outils qui sont maintenus des outils qui sont propres des outils qui marchent bien et voilà je pense que ça ça fait partie de cette phase de la vie d'un chercheur en sécurité à mon âge que vous pouvez supposer je commence à être vieux donc l'usb armory l'idée c'est de faire une enclave sécurisée dans un format très simple très compact un petit périphérique usb et tamago c'est né de notre besoin d'écrire du logiciel d'une meilleure façon pour ce genre de matériel donc c'est quelque chose qui a paru pendant qu'on avait ce qu'on faisait ce voyage du créer ce hardware et c'est venu d'un scénario très simple qu'on a rencontré quand on faisait nos tests sur des systèmes embarqués je crois fermement que comme les langages humains si vous voulez coder pour un périphérique donné dans un langage de votre choix vous devriez être capable de le faire et si ce langage pour une raison donnée son implementation génère un compilateur qui est pas assez rapide pour que vous ayez un projet qui réussit sur le hardware que vous voulez c'est pas forcément votre faute ça devrait pas être votre faute c'est pas vous qui avez choisi le mauvais langage il n'y a pas de mauvais langage le langage devrait s'adapter à vos besoins à votre style en tant que programmeur en tant que développeur on devrait idéalement ne pas avoir à soucier de des optimisations dans le compilateur idéalement tous les compilateurs devraient générer du code machine aussi efficace quel que soit le langage si vous voulez faire des maths dans une requête sql ou en go en rust en piton en assembleur etc idéalement non on parle d'un idéal à la star trek le vaisseau after prize dans un monde comme ça tous ces compilateurs devraient générer le même bycode puisque l'intention qu'on exprime dans le code c'est la même quelle que soit les détails d'implantation mais bon on vit pas dans un monde idéal on vit dans le monde réel et ça veut dire que les développeurs doivent faire des choix notamment de framework de langage les développeurs doivent garder à l'esprit l'implémentation que le langage reflète les implementations supportées par ce langage des implements sont supportés par le matériel qui le cible et donc on a généralement deux scénarios très distincts on a du hardware qui a des visibilisations parce que c'est utilisé un micro contrôleur c'est utilisé parce que les ingénieurs veulent simplifier leur leur design ils veulent faire des économies tout un tas de raisons et souvent les le seul choix qu'on peut vraiment faire pour programmer ces systèmes c'est d'utiliser des langages bas niveau et qui sont unsafe typiquement c c typiquement c'est le cas pour faire des tokens cryptographiques ou des diodes hardware qui servent à implémenter physiquement des limites des frontières de sécurité entre différents périphériques il y a aussi des périphériques alternat des objets ou ce qu'on appelle des des smart object tout ces trucs là ils sont écrit dans des langages bas niveau on sait en général ce qui est pas sûr d'un point de vue la science qu'elle est ou pour éviter les bugs alors que si on pouvait utiliser des langages de plus haut niveau on peut coder dans n'importe quelle langue n'importe quelle langage et pour ça on a besoin d'avoir le support du matériel qu'on veut cibler non si on veut un système off chip qui peut faire tourner go ou piton etc on doit déplacer cette complexité d'un endroit un autre la complexité de l'un safeness du langage on l'enlève de ce qu'on voit nous en tant que développeur mais on la distribue dans le reste de la stack parce que maintenant faire tourner les nukes ou faire tourner des drivers etc et on importe en fait des millions de lignes de code qui sont pas réellement nécessaires pour la tâche qu'on veut faire et on sait que la complexité c'est l'ennemi de la sécurité et de la fiabilité et si on veut programmer un système dans un langage au niveau on n'a pas envie d'importer toute cette complexité de façon cachée un peu de la mettre sous le tapis et de faire tourner notre applicatif au-dessus de ça après tout la la fiabilité et la sécurité c'est les raisons pour lesquelles j'ai choisi ce langage du niveau donc on a ces deux scénarios et il n'y en a pas un qui est vraiment idéal et on peut voir à l'heure actuelle qu'il y a un peu un changement on passe des systèmes off chip qui étaient vraiment très simples et maintenant on a des systèmes qui sont plus compliqués par exemple ce que vous avez dans un routeur à la maison ou dans des objets de l'interne des objets qui commencent à avoir plus de capacité de calcul et du matériel plus complexe et même si ces systèmes sont plus avancés maintenant on voit toujours des applications qui tournent dans un user space sur une grosse stack complexe au niveau logiciel et c'est le cas parce que il y a des bugs dedans et c'est le cas ça parce que le c c'est un langage compliqué c'est quelque chose qui est admis maintenant tout le monde se rend compte c'est très difficile d'écrire du c au niveau d'application qu'on va faire tourner en production parce que la plupart des développeurs ne sont pas des experts en c et on va avoir des bugs dedans quand même et donc maintenant quand on construit du hardware basé sur un système off chip un soc on n'a pas envie d'écrire du c bermeterre mais on n'a pas non plus envie d'avoir une application entre dans un langage de haut niveau qui tourne sur un système de position compliquée et donc notre but c'est de réduire la surface d'attaque des systèmes embarqués dans le dans le vent toutes les dépendances du code c qu'on n'estime pas nécessaire juste le strict minimum pour ce qu'on veut faire et la seule manière de le faire c'est d'enlever toutes les dépendances qu'on aurait sur du code c et on veut éviter de déplacer la complexité de la cacher et on veut passer sur un langage de haut niveau comme beau go mais directement en bermeterre et donc c'est vraiment inspiré par notre projet de créer l'armory usb je vais supposer que la plupart d'entre vous connaissent déjà un peu go peut-être que certains d'entre vous connait rest mais go c'est un peu l'ampe chose et donc vraiment tout est dans le choix d'utiliser le langage qu'on veut alors pourquoi go alors d'abord bon petit disclaimer avant qu'on rentre là dessus on sait qu'il y a des flémoirs des sentiments à propos des langages etc alors c'est pas une présentation sur est ce que le langage x est mieux que le langage y qu'on ne sait pas est ce que c'est pas à propos de est ce que go est mieux que rust etc simplement on pense que il y a des langages que aujourd'hui un petit peu moins de chance de réussir dans certains environnements et il faut leur donner leur chance aussi donc c'est pas pour dire que go est mieux que rust c'est pour avoir le choix et donner le choix de go donc on va peut-être parler un petit peu de sécurité d'échelle alors peut-être que si vous connaissez rust vous aurez envie de mettre le air à un autre endroit du diagramme mais c'est vraiment totalement votre choix mais bon grosso modo on dirait que go est un peu plus facile que rust la courbe d'apprentissage un petit peu plus facile en go par rapport au rust rust est beaucoup mieux que c c'est un ce langage beaucoup plus sûr le c donne beaucoup plus de contrôle sur le matériel mais qui est beaucoup plus difficile pour faire des implementations correctes et donc go est plutôt rapide c'est plus rapide par exemple que ruby et c'est un meilleur choix pour faire des binaire qui vont tourner sur de l'embarquer donc ce qu'on voudrait c'est un petit peu réparer ça pour le langage go alors une des raisons pour lesquelles on veut faire ça c'est parce que bon voilà un peu la configuration d'un firmware sécurisé standard on a bon un bootloader donc secure boot par exemple et avec une authentification du firmware et le bootloader va authentifier le noyau linux et donc c'est ce qui bootstrap tout le tout le système de du chiffrement par exemple si on a une partie en chiffré etc ok driver il va communiquer avec le soc pour trouver des choses stockées sur cette puce et donc voilà c'est la chaîne typique d'une boot vérifiée pour vérifier la fiabilité des données et donc on va se placer dans un scénario par exemple on va faire un portefeuille de cryptomonnaie ou un firmware dans le domaine de cryptographie et on imagine qu'on ne rend envie de le code d'un go bon par exemple il y a une bibliothèque standard de go pour un peu tout pour le tls pour les cryptos on a du code qui est propre et sympa mais maintenant on a envie de boiter cette image sur quelque chose comme l'armory usb et faire juste les tâches très simples de déchiffrer le procédure et de passer à la suite donc on a passé tellement de temps à nettoyer et le code du firmware que on a pas ce temps de temps à nettoyer le code du firmware on a quand même travaillé tout ce système on doit se trimmer les linux on travaille les drivers parce que faut parler au système on doit s'étrambler tout un user space on a probablement busybox dedans si on a essayé d'enlever les choses pas utiles il faut probablement aussi on a on a pu enlever beaucoup de choses avec exemple build route etc mais ça semble quand même pas idéal on pourrait optimiser ça beaucoup plus et ça c'est un exemple que je donne pour l'usb amory mais ça se généralise énormément d'autres plateformes toutes ces plateformes hardware et qui veulent des langages de haut niveau utilise ce sème paterne quand il veut le cibler un système on chip donc ce qu'on veut faire nous c'est qu'on veut garder la facilité d'utiliser go pour du développement mais on veut gagner plus de contrôle sur le hardware donc on veut déplacer en quelque sorte le go vers la gauche sur le diagramme et on veut enlever cette boîte rouge sur le diagramme avec plein de choses dont on n'a pas besoin mais qui qu'on est obligé de trimballer avec nous donc c'est ça l'idée ce projet alors bien sûr c'est pas un nouveau concept c'est quelque chose qu'on appelle les uniques urnelles ou parfois les os comme bibliothèques les libraries us qui sont du coup des moyens de faire tourner les applications directement sur du bare metal et ça ça réduit bien sûr la complexé de la stack alors il y a des problèmes avec les uniques urnelles parce que certains on va les appeler des fat uniques urnelles des grosses uniques urnelles parce que souvent la plupart d'entre eux ils se contentent de cacher de la complexité il y a pas mal de projets d'uniques urnelles qui vous donnent une API et une documentation et qui vous disent que vous pouvez développer une application de la compilée et que ça va être exécuté directement sur le hardware mais en fait ce qui se passe est que souvent il y a un vrai kernel en dessous parfois un kernel qui vient de quelque chose d'assez complexe comme par exemple net bsd ou free bsd et le framework se contente de mettre de l'abstraction au milieu pour que vous ne voyez pas le kernel vous voyez pas le runtime et vous avez juste l'impression de déployer l'application alors c'est pas forcément mal mais d'un point de vue sécurité ça ne résout pas le problème dont on parlait tout à l'heure et d'ailleurs je pense que ça crée le problème inverse quand je faisais la recherche pour sur ce talk j'ai fait une recherche sur tous les unités d'uniel autour et en général c'est difficile de savoir quel était le kernel qui tournait la documentation vous donne l'impression que c'est magiquement permétal mais en fait c'est pas vrai pour la plupart ils se contentent d'importer du code de net bsd ou free bsd la plupart sont basés sur des kernel third party comme mini os qui est aussi créancé mais qui est bien sûr beaucoup plus petit que free bsd et la plupart ne sont pas forcément des choses qui ciblent spécifiquement du bair métal c'est-à-dire qu'ils se s'intéressent pas forcément à tourner sur des system on chip ils s'intéressent plus à tourner par exemple sur le cloud donc ils ont tous le support des hyperviseurs comme par exemple xen qui n'est pas du tout ce qui nous intéresse nous ici donc pour toutes ces raisons la plupart des projets d'unie kernel qu'on a pu trouver ça n'allait pas vraiment pour ce qu'on voulait faire nous sur de l'embarquer puisque ça n'atteint pas le but qu'on s'est fixé notre but à nous c'est de se débarrasser de c on ne veut aucune dépendance sur du code écrit en c quand mon firmware tourne et bah si j'utilise un hypervisor aussi j'ai un hyper un kernel qui écrit en c on peut le cacher on peut l'abstrait autant qu'on veut mais ça ne résout pas le besoin que moi j'ai ici donc c'est vraiment pas ce que nous on veut l'autre problème c'est que quand on parle de sécurité c'est une kernel et c'est normal ils veulent supporter toutes sortes d'applications ils veulent vous dire que vous pouvez écrire votre application dans le langage que vous voulez et on vous pouvez ensuite l'exécuter ou ils veulent aussi être des systèmes de rotation des systèmes d'exploitation quelque sorte et supporter plusieurs langages mais si vous avez plusieurs applications dans des domaines de confiance différents sur la même machine ou si vous avez une application qui écrite dans un langage unsafe comme c vous voulez probablement dans ce cas là avoir un kernel standard et que les gens utilisent parce que vous voulez de l'isolation entre les processus vous voulez des stacks canaries vous voulez toutes ces fonctionnalités de sécurité toutes ces bonnes choses que la complexité d'un os apporte donc on pense dans notre approche que les uniques kernels de ce sens de ce sens là sont intéressants mais nous ce qu'on veut c'est qu'on veut faire tourner un unique langage et on veut faire tourner une seule application donc on n'a pas envie de s'intéresser non plus au cloud on ne veut pas se baser sur un hypervisor et ça ça explique aussi pourquoi est-ce qu'on a choisi go parce qu'on voulait donner une chance à go déjà puisqu'on pense que c'est facile à prendre que c'est un langage dans lequel on peut être très productif et aussi c'est important pour nous il y a une librairie standard cryptographique qui est vraiment très utile et très agréable à utiliser donc rust a déjà prouvé qu'il pouvait avoir du succès dans le monde du berr metal mais go n'a pas encore eu cette chance jusqu'à présent et c'est pour ça qu'on voulait lui donner cette chance là dans ce projet alors en résumé qu'est ce qu'on veut faire c'est important de réfléchir à comment on veut le faire passe qu'est ce qu'on va faire parce que tout le monde peut faire du go tout le monde peut comprendre l'effort de mettre go sur le berr metal mais ce qui est important c'est de savoir comment on va le faire pour qu'il y a un petit peu de confiance donc tamago l'idée est de trouver le chemin de moins de résistance dans les patchs sur go pour y arriver donc vraiment des patchs minimaux pour supporter proprement le berr metal donc on va commencer par définir une nouvelle variable d'os pour go donc là il ya déjà windows linux d'autres os et donc on a créé créé une autre variable go s tamago et avec l'architecture armes comme ça on va pouvoir tourner sur du berr metal ça c'est le principe de tamago et ensuite on a développé un ensemble de paquets qui vont gérer le support de la carte les drivers le matériel donc pour s'en prendre un soc rm qui est assez standard donc un membre de la famille imx 6 exp et notre but c'est toujours de développer nos applications de sécurité en utilisant les les outils open source standard alors il y a eu des efforts similaires sur go dans le passé mais bon pour diverses raisons ils ont pas totalement correspondu à ce qu'on voulait faire principalement deux projets qui sont encore maintenu donc le projet biscuit qui voulait créer un noyau pour supporter non seulement des applications en go mais aussi des applications écrites dans n'importe quel langage en proposant une interface posix etc il est plus très maintenu il y a pas mal de complexité pour l'allocation mémoire les freds etc et pour toutes ces raisons c'était pas exactement ce qu'on voulait utiliser à notre projet qui est plus très maintenu c'est guert donc c'était une une adaptation de biscuits pour toujours pour seulement pour des applications en go qui est pas exactement ce qu'on voulait non plus ensuite il ya atman os qui était présenté je crois il ya trois ans c'est assez similaire à tamago mais donc il cible l'hypervisor xen et donc c'est pas exactement pas du tout ce qu'on veut ensuite il y avait tiny go donc si vous connaissez un peu l'écosystème bon c'est assez actif et très vivant c'est pas exactement ce qu'on veut parce que c'est une réimplémentation complète du compilateur go donc c'est un compilateur différent et pas celui d'origine qui cible les micro contrôleurs et pas les systèmes chip et donc il ne supporte pas du coup tout le runtime et on peut pas vraiment faire du go venir et puis un tout nouveau projet publié à quelques jours donc c'est embedded go gant embarqué donc il supporte arm thumb et en ajoutant en fait carrément le support à ça puisque on l'a pas nativement dans go et donc ça ajoute go s égale no s pour la variable d'architecture c'est pas un peu différent de ce qu'on veut faire mais c'est vraiment très intéressant tous ces projets bon malgré le fait qu'ils soient bon soit pas maintenant ou etc qu'on les aime ou pas donc ça aime ça vraiment ça a réussi à prouver que c'est possible donc notre approche est pas de savoir est-ce que c'est possible mais est-ce que c'est possible sans polluer le compilateur est-ce qu'on peut le faire vraiment proprement et en fait tous ces projets nous donnent quelque part l'assurance que c'est possible alors je travaille en sécurité informatique donc pour nous on entre dans un territoire type compilateur etc c'est un peu un nouveau domaine pour nous mais on doit quand même respecter nos principes fondamentaux notamment créer la confiance parce que il ya pas mal de projets des uniques urnelles etc et ils sont jamais vu la production alors c'est vraiment sympa des des des gens passionnés qui croient ce qu'ils vont faire qui dépasse un peu les limites de la technologie mais mais pas vraiment en production alors nous on veut quelque chose qui est fait vraiment de manière minimale la manière la plus propre possible comme si on voulait l'envoyer upstream pour que ce soit viable donc on va patcher le compilateur vraiment de la manière la plus minimale possible et de même on ne veut pas non plus polluer le runtime à des points que les chercheurs en sécurité trouvraient insupportable et donc on veut faire les modifications les plus petites possibles pour correspondre au style habituel l'équipe de développement de go de sorte que ce soit vraiment un maintenant dans l'avenir donc donc on a vraiment conçu ça pour une inclusion hypothétique upstream plus tard et à la fin on a on est arrivé en 3000 lignes environ de changements dans le compilateur c'est tout on a vraiment cherché à réutiliser du code des architectures existantes de l'hébré standard go et on est juste on essaie de devoir juste un seul import à la fin dans l'application si vous n'avez pas besoin d'utiliser mesteries vous n'avez pas besoin de le savoir et d'essayer de supporter des applications go standard sans aucun problème et donc en plus de ce qu'on peut y faire on fournit aussi des drivers pour pouvoir utiliser un certain nombre de périphériques donc avec ça on obtient tous les avantages du compilateur go de origine les build reproductibles etc alors il ya trois catégories différentes de modifications qu'on a fait sur le compilateur alors d'abord de la glu donc c'est des patchs qui ajoutent le mot clé tamago à la liste des architectures supportées bon ça je s'ajoute dans toutes les définitions que on supporte aussi tamago donc ça c'est nécessaire pour activer cette architecture voilà en plein de fichiers donc on change vraiment une toute toute toute petite partie de plein de fichiers ça a vraiment aucun impact sur la stabilité ou sécurité ensuite on a un deuxième ensemble de patch donc qui est le le principal en fait donc environ 2700 lignes qui réutilisent du code existant du runtime pour l'exécution bärmétale c'est un peu un peu Frankenstein mais donc par exemple le question mémoire sur plein 9 presque totalement réimplémenté donc on l'a repris et on a juste changé une ligne pour pouvoir le lancer sur le bärmétale parce qu'il utilise le syscall brk pour louer de la mémoire sur le bärmétale bon on a un seul espace un seul espace mémoire on a juste un peu à louer des pointeurs dedans et on a juste une ligne à changer à l'intérieur pour les locs donc il y a une structure de loc qui est réimplémentée dans go lang et on peut prendre le web assembly qu'on a vraiment réutilisé tel quel et il y a vraiment que à l'intérieur que trois appels l'os extérieur et on l'utilisera pour les pour les timers et comme il y a cette séparation vraiment abstraction du système c'est facile pour nous et c'est vraiment agréable de pouvoir s'intégrer et utiliser notre propre système qui est du coup du bärmétale à la place de l'os dans ces bout de code donc à un autre exemple ça c'est nacle qui est un file système dans la mémoire qu'on a juste réutilisé sans modification donc ce groupe là de modification c'est là on a le plus de lignes parce qu'on a quand même dû copier les fonctions de par exemple même un score plan 9 on a dû le copier et puis renommé en même un score tamago donc ça fait beaucoup de lignes mais c'est très peu de changements au final et puis on a du nouveau code une douzaine de fichiers sur environ 600 lignes et ça c'est des fonctionnalités qui sont spécifiques à tamago globalement l'essentiel c'est l'initialisation des corps sur arm c'est quelque chose qui est nécessaire pour tous les os tous les bootloader etc et on a aussi du code qui fournit des points d'intégration pour votre application pour par exemple pouvoir comprendre combien de memoire on utilise où sont les où est la mémoire etc donc ça a été en fait une surprise pour nous de se rendre compte que le runtime de go a très peu de dépendance il n'y a vraiment pas grand chose qui dépend de l'os c'est ici l'ensemble des modifications ont eu besoin pour faire tourner go sur du berr metal puisque le compétateur nous permet d'être faire ça donc voilà le layout de mémoire qu'on utilise on a un tas une stack tout ça c'est assez standard au final et on utilise des variantes de ça selon la board sur laquelle on tourne le runtime de go il y a trois composants là dedans on a le support dans le runtime lui même alors voir un exemple de ce qui se passe dans le fichier os tamago arm go et on peut voir ici qu'on a des hooks des points d'intégration avec des fonctions qui doivent être définie par l'application c'est à dire qu'on ne veut pas mettre d'information sur les différentes boards tous les variantes de hardware qui peut y avoir et les différents périphériques etc on veut pas mettre ça dans le runtime donc on a une fonction générique pour initialiser le hardware une fonction pour afficher sur la console une fonction pour obtenir des données aléatoires une fonction qui initialise ça une fonction pour le temps quand on veut le runtime a besoin que l'application fournisse ces choses là on a aussi des variables pour dire où est ce que la ram commence où sont les offsets et où il a taille de ram ensuite cette fonction ici c'est quelque chose qui est juste lié à l'architecture en elle-même c'est pas spécifique il ya une board particulière c'est quelque chose pour armes en général et ça ça fait partie des modifications du compilateur go qu'on a fait ensuite on a le paquet pour le soc ça c'est vraiment très simple tout ce qu'on a à fournir c'est ces des implementations des hooks qu'on avait dans le runtime donc les variables d'où commence la mémoire et d'où est l'offset pour la stack et ensuite on a ici pour la borde on doit dire qu'elle la taille de la ram puisque la taille de la ram va être la même pour différentes associés mais sur différentes bordes on a peut-être plus de rames que sur un sur d'autres le début de la ram va tout le monde droit mais la taille sera différente ici aussi dans le package usb armory on dit aussi quand quelque chose va être affiché sur la console qu'est ce que ça veut dire dans le cas de l'usb armory c'est la deuxième uart donc c'est le port numéro deux et donc ça c'est quelque chose qui appartient dans le package usb armory et pas dans le runtime donc ça nous permet d'avoir des modifications minimes dans le runtime pour avoir ce qui correspond à un soc particulier dans le paquet du soc dans ce cas là le imxxuel et des informations qui ont spécifique à une borde dans le paquet de la borde dans ce qui est dans ce cas ici c'est usb armory donc c'est vraiment propre comme séparation un autre exemple on a ici des timers donc dans le runtime à mon donné go doit savoir à combien de ticks on en est pour savoir combien de temps c'est écoulé ça s'est fourni de façon externe par l'imx6 le package imx6 qui fourni un support pour les timers qui sont utilisés par l'usb armory parce que c'est ça que l'architecture fourni et on peut aussi on doit utiliser de l'assembler ici puisque c'est quelque chose qui ne peut pas se passer dans go et donc ça c'est la façon la plus efficient de faire ça à bas niveau pour obtenir l'information du timer donc ça c'est parti du code d'initialisation qui fait partie d'environ il y a environ 500 lignes de code comme ça qui est un qui est simplement des choses qu'on ne peut pas faire dans le runtime en lui-même par exemple là on va essayer de changer la fréquence d'horloge puisque c'est quelque chose qu'on aura besoin de faire donc qu'on le fasse nous-mêmes le bout de l'audeur va pas le faire le bout de l'audeur gère différentes fréquences et donc on le peut le coder assez directement en go dans le paquet du system chip pour régler la fréquence voilà quoi ça ressemble en go on a des fonctions pour modifier les registres voilà par exemple le registre pl on met deux bits à zéro à certains 9 à certains 9 7 et en fait c'est ce qu'on trouverait aussi en c bon voilà mais là on go on peut attendre aussi une valeur de on peut attendre qu'une valeur de vena 1 en mettant un loc sur la sur l'horloge on peut régler le diviseur ou etc donc tout ça on peut le faire en go et c'est assez c'est vraiment intéressant en utilisant des langages qui sont sûrs d'un point de vue de la mémoire comme go c'est que donc si on fait quelque chose d'un safe il y a un mot clé pour ça par exemple on go il y a le mot clé unsafe et donc si vous voulez du coup examiner et chercher tous les endroits un peu suspects dans le code et va il suffit de chercher un safe et alors vous avez tous les endroits où il y a de la rythmétique des pointeurs il y en a besoin évidemment dans les dans les drivers mais c'est vraiment facile de les trouver c'est ça qui est vraiment intéressant dans les langages de niveau pour les six calls alors le runtime go utilise directement il se scole pour pas mal de fonctions et donc ça c'est notre principale souci est ce qu'on a est ce qu'on va devoir émuler 50 66 calls et en fait il y en a vraiment un seul en fait qui est qui est vraiment nécessaire qui est bright parce qu'en fait il va être branché sur notre fonction printk et donc comme ça on va pouvoir supporter la sortie standard et l'erreur standard et voilà on en a besoin dans le berr métal si donc sur ces sur ces objets là on n'a pas d'écran mais on écrit sur l'art donc là le paquet du bord qui est à l'extérieur du compilateur va définir sa méthode print à l'extérieur donc à la fin oui à quoi ça ressemble normalement on aurait le runtime go dans le user space dans un os complexe il fait des six calls et ensuite c'est le noyau qui a des drivers qui va parler au périphérique etc dans tamago on vit dans le runtime go le paquet est linké au runtime et il y a le paquet du system chip et de la borde qui sont aussi linkés et à chaque fois qu'on va faire un six call en fait il est juste branché sur le sur le support driver dans le paquet en go mais on est on reste tout dans go et voilà l'exception de quelques petites fonctions initialisation de super runtime qui sont spécifiques à tamago on est sur le runtime standard donc ça c'est le changement et donc on réduit à la fois le nombre de lignes de code mais en fait on élimine totalement le besoin d'utiliser le c parce que en fait alors il reste quand même du c dans le bootloader mais bon on travaille aussi à remplacer ça mais mais voilà pour nous il n'y aura plus aucune ligne de c donc comment on développe on compile ce truc donc vous écrivez du go comme vous l'avez toujours fait et vous importez le paquet de la carte si vous n'utilisez pas spécifiquement le driver c'est vraiment tout ce que vous avez à faire mais pour faire des opérations de base c'est tout ce que vous avez à faire ensuite on compile avec go build comme d'habitude exception de quelques flags pour le linker on a besoin de dire que ça dépend de la planche que de carte et qu'on indique aussi l'adresse du segment texte du binaire donc voilà on met go s tamago go arm set go arch arm et voilà bon là va varier un tamago c'est juste le runtime go avec support pour tamago et ensuite dans le bootloader on a juste besoin de passer le binaire et c'est voilà et voilà et ensuite il va juste lancer cette application comme si c'était un kernel donc on a implémenté des drivers des drivers orientés sécurité pour notre système chip pour montrer que ce serait vraiment utilisé donc le mx6 url donc qu'on a utilisé on va écrire des drivers le premier c'est pour le co-processor de données donc qui propose des fonctions de crypto avec une clé hardware intégré donc on a écrit un driver pour ça qui fait environ 240 lignes de code donc je crois que c'est 10 fois moins que le module kernel linux en fait si on charge ce paquet on peut juste appeler la fonction dirai qui et puis on a des exemples avec ou pas ou sans secours boot et en fait on peut utiliser des structures qu'on crée en go on peut les rendre compatible avec ça avec un petit peu d'effort et les passer directement à la mémoire on crée une structure ici et puis on passe un pointeur des choses dans la structure et puis voilà ça marche et à la fin on va écrire l'adresse de notre structure à louis en go dans un registre et ensuite le matériel peut récupérer ces structures et voilà on écrit un driver pour le générateur de nombre aléatoire donc il y a un il y a un générateur de vrai nombre aléatoire dans la puce qui est initiée au démarrage donc il y a besoin d'une graine au départ et voilà le driver fait à peu près 150 lignes et on l'a branché dans le paquet crypto rend de go et du coup ce sera utilisé dès que vous appelez le paquet crypto rend ensuite on a créé un driver usb et on a tous défense posé question qu'on a à ce point dans cette vie où on a 40 ans et on écrit des drivers pour usb mais quelque chose d'intéressant c'est que avec juste le manuel et si on a le manuel et le condensé c'est difficile mais avec go c'était en fait un plaisir à écrire parce que j'utilisais des channels je pouvais utiliser une syntaxe plus légère et c'était vraiment très agréable quand on développe des drivers en go il ya deux choses inhabituelles auxquelles il faut penser en tout cas inhabituelle pour les gens qui développent en go parce qu'ils ont pas l'habitude de ça il faut penser à l'alignement de vos structures en mémoire puisque il y a beaucoup de hardware qui ne va pas marcher si les pointeurs sont pas alignés donc on a créé une classe pour ça et il faut aussi penser au garbage collector puisqu'il faut garder des pointeurs vers le buffer sous-jacent qui sert à fourdir l'alignement mais c'est le seul détail auquel il faut penser quand on fait un driver en go il ya une autre chose qu'il faut voir ici c'est que à chaque fois qu'on touche le driver on écrit les pages et l'alignement de la page où on se trouve ça c'est parce qu'il y a eu tellement de bugs dans le kernel linux qui ont été liés à une mauvaise écheon des pages on voulait éviter ça donc on a juste mis des références à ça à chaque fois des références à pardon c'est les pages de documentation les pages de mémoire donc on récférence les pages de la documentation à chaque fois pour savoir où on se trouve donc maintenant on a un driver c'était pas très compliqué l'essentiel du code c'est juste de définir des descripteurs on a une paire de fonctions pour définir la configuration de l'ocm on peut même impliquer on peut importer la net stack de google qui est une implementation complète en go des protocoles de base pour faire du réseau et avec ça je peux vous faire une démo de ça donc à gauche je vais démarrer mon usb-armory avec tamago dessus donc ça c'est tamago qui se lance alors ce qu'il a fait là en quelques secondes le bootloader a démarré enfin directement passé la main à go il a initialisé le générateur aléatoire on a changé la vitesse de la clock on a lancé cette go routine il y en a une qui a lu un fichier mémoire il y en a une qui s'est mis en pause pendant un certain temps pour s'assurer que l'implantation est correcte on a généré des quelques normes aléatoires on a généré des signatures cdsa on a signé une transaction bitcoin tout ça la go routine sont toutes compliquées sont toutes terminées on a alloué de la mémoire pour vérifier que le carbat de collecteur marche et là on attend usb et donc si je le connecte à mon autre usb-armory je connecte une usb-armory à une deuxième usb-armory c'est très métal et donc maintenant les descripteurs usb sont évalués et on voit déjà du trafic réseau et si je me connecte à l'usb-armory maintenant alors j'envoie hello c'est juste un serveur echo en udp je peux demander un un rendement aléatoire je peux du beguet de mémoire et je peux aussi faire ça je peux streamer star wars en ascii et si vous pensez que ça tourne pas assez aussi bien que ce que vous voulez en fait le problème c'est pas l'usb-armory c'est windows qui supporte pas très très bien la console donc tout ça à part pour le sauf le bout sauf le bout de l'odeur tout ce que vous avez vu le usb le tc pip tout ça il n'y a aucune ligne en c à l'intérieur c'est du pur go et un petit peu d'assembleur et voilà je trouve que c'est vachement cool alors sur la performance sur la performance comme on s'y attend la vitesse est la même que la même application en go dans un s par exemple les signatures cdsa depuis la test suite sous linux sur le même matériel et sous tamago en fait la vitesse c'est la même c'est vraiment ce qu'on s'attend à voir ça doit être la même chose c'est peut-être un tout petit peu plus rapide parce qu'il y a moins d'overage du système alors il y a quelques limitations quand même donc par exemple sur ce sur ce matériel on a un seul fred donc voilà si vous avez des fonctions avec des avec des boucles assez serrés qui reviennent pas au runtime ça va se bloquer donc c'est en fait bon c'est pas propre à nous c'est ce que qu'on va faire à chaque fois que vous avez go mac prox à un mais voilà il faut que vous revenez au ski du l'heure deux ans en temps mais en général si vous faites une boucle série qui fait rien c'est simplement parce que vous faites des tests alors on doit implémenter un fait le système si vous importez un paquet qui a besoin d'un système que non supporté ça va pas marcher mais ça va en s'y attend si vous faites du cgo bon ça va être possible du moment que le code est stand alone mais bon voilà en fait il y a finalement peu de surprises égaux et plutôt pas mal adapté pour pour faire ça alors maintenant ce qu'on aimerait c'est écrire des fermoirs sécurisés donc des des jetons de sécurité des cryptoportes monnaies etc et donc tout a été fait pour développer l'application sécurisé sur ce genre de matériel donc alors on peut utiliser la complexité sans la sans la sans la cacher on a réussi à donner le choix donner une chance à go sur le baird métal et voilà on pense qu'on a réussi dans les dans les prochains mois on va essayer de construire un peu la confiance de faire accepter au stream donc merci à tous ces gens qui ont permis ce projet et donc là je crois qu'on a quelques minutes pour les deux minutes pour les questions merci beaucoup merci andrea c'était parfait comme temps pour terminer il est 13h37 et on a donc 13 minutes pour des questions alors si vous voulez poser des questions on a des microphones dans la salle vous pouvez aussi poser sur internet avec le hashtag d'extras sur twitter et mastodon et nous avons une question du signal angel de l'internet bonjour alors deux questions sur irc la première est est-ce que le garbage collecteur peut causer des problèmes de performance sur du baird métal et non pas dans notre expérience d'ailleurs quand on utilise du baird métal on peut le désactiver c'est quelque chose que go a toujours eu on peut désactiver la garbage collection vous pouvez aussi contrôler quand est-ce qu'elle tourne et si votre application ne dure pas très longtemps et que l'allocation est facile à prévoir vous pouvez juste tourner sans garbage collection complètement c'est vous qui décidez dans notre expérience on a dans ce qu'on a vu on n'a jamais eu de problème la performance et le comportement du gc c'est vraiment similaire à ce que vous verriez dans une application normale sur un os normal il n'y a pas de changement dans le comportement merci question suivante la dernière de l'internet est-ce que tamago est approprié pour les applications real time toriel et c'est oui ou non quels sont les limitations alors je pense que si on désactive la garbage collection ça devrait marcher potentiellement je suis pas spécialement fan des systèmes toriel de ce que j'ai pu voir en général quand les gens utilisent des systèmes toriel il y a de toute façon tellement de bug que la partie real time ne marche jamais vraiment bien et les gens n'avaient pas vraiment besoin dans ce qu'ils faisaient mais il y a comme des cas d'utilisation typiquement dans le monde de la finance effectivement il y a des cas où c'est nécessaire si c'est un de vos besoins je vous dirais que rust est probablement un meilleur langage pour ça ceci dit c'est possible si vous désactivez la garbage collection parce que au final le comportement est très très facile à prédire sans garbage collection en go alors merci pour votre projet première question est-ce que vous regardez en général le code assembleur qui est généré après la compilation de go deuxième question go marche très bien avec du fosing est-ce que vous avez utilisé du fosing sur la forme et troisième question est-ce que vous avez trouvé des bugs dans le runtime de go pendant que vous avez fait ce portage pour votre plateforme alors oui on regarde le code assembleur on utilise l'assembleur de go nous-mêmes la génération de code est identique à ce que vous auriez comme génération de code sur une autre plateforme armes la target c'est du bermétal mais l'efficacité quand vous faites la compilation c'est la même puisqu'on ne touche pas nous à l'assembleur deuxième question c'est le fosing alors on veut utiliser ça pour faiser l'usb un de nos projets c'est d'implementer un foseur banniveau usb dans l'usb armory qui peut foser l'autre usb on veut aussi comprendre comment intégrer le fosing de ça de façon externe en go donc il se dégo fuzz sur notre programme six jobs auquel on pense à l'heure actuelle et la troisième question était est-ce qu'on a trouvé des bug dans le runtime go et oui si vous regardez sur ce slide ici on a un bug de go qui est intéressant en bas à droite un bug qui a trait à la guerre belge collection donc on a au moins trouvé celui là c'était quelque chose d'un petit peu bizarre donc oui on a trouvé des bugs bien sûr mais on travaille avec les les les gens qui maintiennent le complèteur go et ils sont ravis de travailler avec nous et par contre ça nous a pas bloqué on n'a rien trouvé qui a empêché de réaliser ce projet une question d'internet du signal angel alors trois questions apparemment je crois qu'on a le temps alors vous avez plus facile alors est ce que c'est tamago serait adapté pour d'autres microcontrollers alors pour les microcontrollers vraiment je conseille tinego parce que le vrai de vraiment gros et tinego c'est vraiment bien comme projet c'est une raison d'exister pour les microcontrollers vous utilisez tinego pour les systéments chip tamago bonjour merci beaucoup pour la présentation et pour votre travail alors j'ai envie de cibler l'armory mk1 est ce que ça pourrait marcher alors oui oui on prévoit de supporter l'armory marque 1 et puis le aussi le raspberry zéro et en fait c'est facile de supporter du matériel assez divers et quelques jours de travail et les poules request sont bienvenus on revient au signal angel alors une autre question alors est ce que ça peut tourner sur d'autres processeurs cortex ou seulement le même alors oui ça peut être exécuté sur n'importe quelle systéments chip qui a une architecture armes supporté par le runtime go donc c'est trivial de les faire tourner sur des systéments chip armes v7 et bon pour les autres il faudrait faire quelques modifications donc les changements c'est l'essay sur le matériel donc ça devrait être assez facile de porter sur d'autres plateformes si c'est des systéments chip cortex normalement ça devrait être assez facile à faire merci pour la réponse alors j'ai une autre question alors est ce que tamago pourrait marcher aussi sur l'usbère marie marque mk1 oui oui oui on va vraiment s'assurer qu'on va faire ce support là c'est rapidement alors un développeur c très intéressé demande est ce qu'on peut mettre des breakpoints et des points de trace et mémoire sur dans tamago donc oui oui ça marche très bien avec gdb sans aucun problème sur tamago et c'est vraiment c'est vraiment super alors est ce qu'il y a un support de file system je crois que vous avez mentionné des il y a une implementation on go que vous pouvez regarder le projet je crois fuchsia le projet fusion le projet fusion fourni un driver user space pour fat en go alors oui on avait déjà des implementations en go de fat le projet girth on a parlé avait ça aussi un simple support d mmc donc on va essayer d'intégrer ça dans tamago ça devrait pas être compliqué j'ai juste parlé de fat parce que c'est un format de système de fichier qui est facile ça permet juste de voilà prendre un blob l'écrire il n'y a pas besoin de faire quelque chose de plus compliqué c'est pour ça que j'en ai parlé alors merci pour le talk est ce que vous avez parlé du coup à l'ubstream pour intégrer ça dans la main line go et oui on travaille sur ça alors on veut on angoisse un peu parce qu'on veut que tout soit très propre pour faire ça mais c'est notre but on veut avoir la meilleure chance à pouvoir faire ça et pouvoir upstream et notre conne on est en contact avec l'ubstream et on a depuis le début à implémenter ça de façon propre et respectueuse on n'a pas fait de haq on n'a pas hijacké des trucs qui étaient pas fait pour être hijacké parce qu'on veut pas maintenir le compé le compilateur nous on veut juste maintenir le driver donc on a fait beaucoup d'efforts pour que ce soit dans un état où ça a la meilleure chance d'être upstream et question est-ce qu'il ya une timeline pour ça réponse non mais j'espère peut-être d'ici la fin de l'année qui vient alors question pourquoi ça s'appelle tamago alors on l'a appelé tamago parce que tamago ça veut dire off en japonais et ça contient go et go vie du coup sur du berr metal dans sa propre cookie et voilà et si on le fait tourner sur que musa fait un tamago chi c'est la seule raison pour laquelle on a fait ce projet d'abord on a d'abord inventé le nom et ensuite on dit mais qu'est ce qu'on pourrait faire avec un nom comme ça nous n'avons pas d'autres questions de l'internet nous avons une question sur le micro numéro 1 alors aujourd'hui souvent les systèmes embarqués ont un écran comment ça marche alors l'usb armory n'a pas d'écran donc c'est pas quelque chose sur lequel on s'est focalisé mais ceci dit il n'y a pas de raison pour lequel on pourrait pas avoir un driver vidéo là dessus ce serait peut-être pas aussi performant que ça puisse l'être mais si vous faites des écritures en dm ag vous êtes intelligent il n'y a pas de raison pour laquelle ce serait lent c'est pas quelque chose auquel nous on a passé du temps nous ce qu'on veut c'est avoir des smart cards plus intelligentes des hsm des tokens d'authentification on a bluetooth sur l'usb armory on a l'usb si on veut vraiment une interface utilisateur ce serait une application mobile ou alors c'est quelque chose qu'utilise le réseau mais oui pourquoi pas avant nous d'autres questions et bien je suppose que non et bien dans ce cas merci beaucoup andréa applaudissement s'il vous plaît