 Donc le dernier speaker pour ce matin est Tramul, qui fait une recherche incroyable sur bootstraps et des laptops plus secures, qui fait ça en bougeant le trust dans le ROM protégé, qui construit en formoir une source big-up pour ça. Et il en croise aussi la recherche dans ce domaine. Donc je suis Simone Tramul seul avec tout signal d'Igmasme. Pendant ces deux dernières années, j'ai recherché les formoirs et comment ça affecte les systèmes. Donc il y a deux ans, j'ai présenté un travail sur Tanner Strike. Donc c'est la première attaque formoir contre des MacBook qui permettait un attaqueur d'override le bootrum d'un motherboard. Donc l'année d'après, j'ai fait une collaboration avec deux personnes qui travaillent maintenant chez Apple pour faire du travail sur des firmwares. Et ils ont porté certaines vues d'invalidation UFI Windows sur Mac et montré que la plateforme UFI permet des attaques très portables qui peuvent être transférées donc entre Windows et Mac. Plutôt que de casser des choses, ce que j'aimerais faire c'est démonter des choses et comprendre comment elles fonctionnent. Et documenter des choses afin que d'autres personnes puissent construire des systèmes au-dessus de ça. Donc c'est pour ça que je suis très heureux de vous parler aujourd'hui de mon projet. Donc un projet d'un firmware open source, un bootloader pour des laptop et des serveurs. Donc le nom c'est un jeu de nom sur la distribution Tels, donc un Linux stateless qui ne laisse aucune trace sur la machine. Donc on va commencer par parler sur pourquoi la sécurité de firmware est tellement importante. Donc ça c'est le code qui est exécuté par le CPU quand il sort du reset. Donc c'est la première instruction que le CPU va exécuter. Donc c'est une position très privilégiée qui pourrait contourner toutes les autres protections hardware ou softwares. Donc il n'y a pas de shortage de talk qu'on peut parler sur des vinaubatisées de firmware. Donc une que j'ai beaucoup aimé c'était l'année passée à Defcon, donc sur des firmware Intel qui montraient que le firmware Intel pouvait contourner les hyperviseurs. Qui montraient comment du firmware bugger permettait un guest non privilégié à l'intérieur d'une machine virtuelle pouvait faire une escalation privilège à l'intérieur de l'hypervisor. Donc pour cette raison c'est très important que les vinaubatités firmware et les bug firmware devaient être patchés. Donc ça c'est pas seulement des recherches théoriques, donc on sait qu'il y a des organisations militieuses des groupes de hacking qui vendent des rootkit firmware pour un importe key qui est d'accord de payer. Donc c'est utilisé aussi dans des APT. Donc c'est des APT très persistants parce qu'ils sont justement dans les ROM de boot de la carte mère. Donc ils sont réinstallés en réinstallant un scene d'opération, même en changeant le disduire ils sont encore là. Donc certains vendeurs bundlent même ces rootkit dans leur ROM officiel. Même après réinstaller le scene d'opération propre, ces rootkit réinstallerait leur propre version. Donc certains ont des vinaubatités qui peuvent être exploité par des attaqueurs. Donc dans ce cas particulier le vendeur a reçu un objet de firmware qui a patché cette vinaubatité. Donc les utilisateurs ne pouvaient pas mettre jour le firmware de leur machine. La plupart des vinaubatités de firmware en réalité ne voient jamais de patch et ne sont jamais déployés vers les utilisateurs finaux. Donc en partie une raison c'est que le firmware est créé par 4 ou 5 compagnie qui sont à distance, qui sont très loin et très abstrait par rapport à l'utilisateur final. Donc quand une vinaubatité est patchée, tout en haut d'abord elle doit être implémentée par le vendeur de BIOS qui ensuite vend ça au packageur de device, qui le vend finalement seulement au producteur de device. Donc il y a toute une chaîne finalement d'acteurs impliqués et pour qu'un patch s'allait pousser jusqu'à l'utilisateur final, il faut beaucoup de coopération entre les différentes entités. Parfois ça doit même passer encore par le vendeur de système d'exploitation. Donc ça c'est la raison pourquoi la plupart des produits ne reçoivent jamais d'objets après qu'ils aient été vendus. Donc il y a une exception c'est Apple qui construit leur propre firmware et donc il a été toujours très satisfait avec Apple qui ont toujours construit des patchs même pour des très vieux firmware. Donc il y a très différent de ce que les autres vendeurs de firmware font. Donc compte EFI a été introduit, ça a apporté beaucoup de complexité et que la communauté Linux était très sceptique. Donc il y a presque autant de codes qu'un système d'exploitation pour l'environnement UFI. Le bios n'était pas forcément meilleur parce qu'il y avait aussi ses propres problèmes mais c'était petit, c'était simple et ça passait sur 4K. Donc maintenant la plupart des systèmes sont en fait livrés avec à la fois un BIOS et un système UFI donc en fait on double la surface d'attaque. Donc les mises à jour sont rares comme dit précédemment. Les patchs, s'ils sortent une fois, ils mettent un long moment si... Enfin, si toujours est-il qu'il vienne à une citade finale, ça prend un très long moment jusqu'à s'y déployer. Donc c'est pas une réalité satisfaisante pour quelque chose qui est aussi privilégié qu'un firmware. Donc pour lui, le firmware doit être construit de manière open source, doit être flexible afin qu'il puisse être adapté à nos besoins, à nos systèmes. Il doit être construit avec du software qu'on comprend. Il peut être réutilisé aussi dans différentes applications afin qu'il puisse être testé. Il doit être construit de manière réproductible afin qu'il puisse être sécurisé aussi contre des attaques de la chaîne de build. Il doit pouvoir être mesuré afin d'être sûr qu'est-ce qu'on flash sur le système puisse aussi être... Enfin, soit aussi ce qui est rené sur le système. Donc la philosophie derrière heads, c'est construit sur l'open source core boot, plus un Linux kernel ROM. En plus de ça, beaucoup de recherche de sécurité tools. En utilisant Linux comme bootloader, c'est pas une idée particulièrement nouvelle. Donc déjà dans les années 90, Cotr, il a commencé à construire des clessures Linux. Il était très frustré avec la non-flexibilité du DHCP, enfin du boot DHCP. Donc même avec cette frustration, il a construit un clesseur qui était dans les 30e plus rapide du monde. Pendant ce temps, ses collègues construisaient aussi des gros clessures et a remarqué que le BIOS enumère tous les bus, trouve le kernel Linux et qu'ensuite le kernel Linux ré-numère tous les bus. Pourquoi est-ce qu'il le fait ça ? Il trouve ça inutile, il trouve ça bête pour en le faire double. Donc son idée, c'est de construire une version Linux qui exécutait depuis la ROM. Donc il a appelé ce projet Linux BIOS et ça a été utilisé pour le clesseur MRC, qui a fini par être la troisième machine la plus rapide dans le monde en 2008. Linux BIOS a connu une ré-facteur majeure qui a été rappelée Coreboot. Google a choisi d'avoir du site Coreboot sur leur Chromebox, qui a le seul maintenant laptop qui n'est pas basé UFI qu'on peut acheter aujourd'hui. Donc Ron a été à Google en 2011 et a continué de travailler sur un projet Coreboot. Donc Coreboot a trois étapes par lesquelles il passe quand on démarre la machine. Donc le premier était un tout petit peu donné d'assembleur. D'assembleur 16 bits, donc même les laptops 64 bits utilisent des instructions 16 bits de boot. Donc ça ensuite s'est setup en environnement C, qui passe en, non l'étape prime qui fait à peu près 70 k. Lors de l'initialisation du TPM, le module trustee, c'est dans le ROM stage, avant que le RAM est initialisé pour l'achéner trust. Le ROM c'est à peu près 60,000 bits, et le RAM c'est de 40, 40 k. Alors le RAM stage énumbrise les devices, mais il ne va pas les initialiser. Après ça il va au payload. Le process complet prend un seconde d'aller au payload, alors au code du utilisateur. Donc sur quelques des X230, il peut passer depuis le power off jusqu'à un shell interactif en moins de seconde. Parce qu'on a maintenant Linux à ce point, on a toute la flexibilité qui vient avec ça. On peut implémenter des scripts de boot, avec toute la puissance du shell ou avec l'environnement C. Donc on n'est pas limité par les fonctionnalités limitées de l'UFI. Linux supporte aussi beaucoup de systèmes fiers, et supporte beaucoup de méthodes d'occurricion. Donc il y a un contraste avec UEFI qui supporte que des systèmes fiers non cryptés, qui doivent être sur le début du disque. C'est beaucoup plus flexible pour trouver le device boot. Donc il y a un adage dans la communauté open source qui avec assez d'oeil, assez de yeux point déçu, il y a tout qui a chaleau. Donc le Linux a été revu et revu, et encore revu par des milliers de yeux. Donc les versions UEFI n'ont pas une telle scrutinerie. Donc tant les drivers UEFI que les systèmes qui explotent au dessus de là augmentent l'attaque de surface, par la surface d'attaque. Donc en utilisant Linux, on fait réduire notre surface d'attaque de manière dramatique. Plus important, tant encore en bout que Linux est open source, donc c'est facile de construire des versions custom pour des systèmes fichiers qu'on utilise. C'est possible de patcher des bugs de manière indépendante. Il n'y a pas besoin d'attendre que le patch soit intégré dans le release officiel. Donc le troisième composant majeur de Heads, c'est un tool plus... Ça permet un kernel en cours d'exploitation de faire un shutdown graceful et de rebooter un nouveau kernel sans repasser par tout le processus de boot. Donc ça permet à des applications de cluster de faire des reboots très rapides. Et dans le cas de Heads, ça permet d'agir comme bootloader. Heads est très petit, ça doit passer sur 4 megabytes de ROM. Donc c'est pas quelque chose qu'on peut utiliser comme systèmes fichiers en day-to-day. J'espère que ça ne va pas exploser de nouveau sur moi. Parce qu'on a le shell, donc la plupart des choses de Heads sont implementées comme shell scripts. Donc dans ce cas, on a été capable de passer un nouveau set de paramètres en ligne de commande. Donc on peut même démarrer un hypervisor. Et tout ça peut se passer de manière très rapide. Avec aussi bien un bon degré de sécurité. Donc ça c'est les building blocks sur lesquels Heads repose. Donc ça nous donne une belle plateforme pour commencer à expérimenter avec différentes features de sécurité. Avant qu'on continue plus loin de Terri de la peintre, il aimerait coûter son amie, qui dit que mon modèle de trading n'est pas le tient. On a chacun différentes choses qui... Chacun veut protéger ses différentes choses, mais c'est ok. L'avantage de Heads comme Open Source est qu'on peut construire des systèmes adaptés au modèle de menace individuel de chacun. C'est peu que mon système ne soit pas fait pour ton modèle de menace, mais tu peux très facilement changer afin de refléter ta réalité. Donc le firmware n'est pas seulement notre CPU. Le firmware est aussi dans notre carte de wifi, notre GPU, notre disque SSD, notre clavier. Et tous ces devices pourraient essayer de finalement pervertir, subvertir le procès de boot. C'est une des menaces qui vous concerne, c'est très utile à suivre. Donc lui, il sort finalement tout ce qu'il pourrait signifier de menace. Alors Heads, non, il n'est pas si simple à installer comme une distribution Linux normale parce que ça doit être installé dans le ROM du système, du machine. Alors cette chip flash a une protection en hardware. C'est normalement une lecture. Alors ça, c'est une bloc de boot immutable pour le premier chaine de trace. Alors une boîte de base qui protège contre des classes d'attaque. Alors si ça, c'est une menace qui vous concerne, c'est une idée de couvrir cette chip dans d'époxy. Cette module est aussi capable de protéger la machine des autres devices sur le port de base qui peuvent être une menace. En congrès, deux ans dernière, il y a eu un talk sur ça. Alors c'est les management engines, les inter-platformes. C'est une chip avec une bloc de code de 5MHz qui accélère direct au système ORAM qui peut écrire sur la carte graphique, carte de net, et peut lire le net, même quand la machine éteint. Ça, ça m'a beaucoup concerné et j'ai passé beaucoup de temps pour regarder comment c'est construit. Donc il a remarqué qu'il pouvait construire un format modifié qui enlevait finalement toutes les fonctionnalités rootkits. Ça prend les 5Mb et puis ça réduit à peu près 40K d'espèces. Il ne sait pas exactement ce que ça fait dans ces 40K, mais il sait que ça ne peut pas, ça n'a au moins pas de driver, de device ou pas de machine virtual java. Donc il a fait ça sur tant Sunny Bridge que Ivy Bridge, et aussi sur les nouveaux CPU Skylake. C'est encourageant de voir que si on peut appliquer ça à plus de hardware courant, c'est possible de passer de quelque chose d'ancien à un peu plus nouveau et sécurisé. Donc le Management Engine c'est pas le seul device qui pourrait essayer de divertir le processus de boot. Donc l'architecture d'Intel UFI recommande que le fermoir allume, enfin lance, le VTD. Jusqu'à maintenant, pour autant qu'il ne sache, il n'y a pas un seul fermoir UFI qui tire profit de cette fonctionnalité. Donc ça n'aide pas vraiment pour la sécurité si on ne l'allume pas. Donc nous on n'a pas de problème d'utiliser, enfin, d'élèver ager cette production. Un autre moyen que des devices pourraient essayer d'interférer avec le processus de boot c'est donner du code qui serait exécuté par le BIOS à travers un driver des devices qui peut essayer de faire différentes choses comme extraire des motes pass. Donc ce problème a été initialement relevé en 2007 à la Black Hat. Et ensuite, à nouveau en 2012, puis finalement par lui-même sur Thunderstrike. Et finalement, la semaine passée, il y a un fixe officiel qui a été sorti pour patcher sa viabilité. Donc ceux qui utilisent Core Boot, ils ont comme option, qui peuvent dire que cette menace est importante pour moi et que j'aimerais désactiver cette fonctionnalité. Donc ça pourrait enlever des fonctionnalités, mais c'est quelque chose qu'on peut choisir ou pas d'avoir. Ça dépend du modèle de menace pour chacun. On n'utilise pas finalement les drivers des devices parce qu'on se base sur les drivers fournis par Linux vu que justement, l'avantage est sur une plateforme Linux. Donc maintenant, on a tout nos éléments pour construire et on espère avoir protégé le processus de boot. Donc maintenant, la question, c'est comment on sécurise les secrets sur une machine. Donc lui, il est un grand fan du TPM, donc la plateforme de trust. Donc ça n'a pas reçu un accueil très chaleureux parce qu'il a commencé à utiliser pour les DRM et puis d'autres choses, un peu style pour l'utilisateur. Mais comme nous, on contrôle le TPM depuis la première instruction dans le boot block, c'est possible d'utiliser pour des choses que nous, on veut. Donc on n'a pas besoin d'activer le DRM, mais on peut l'utiliser pour protéger nos secrets. Donc comment ça le fait, c'est qu'il regarde quelque code à exécuter quand le système démarre et il lâche ce code dans des règles spéciales appelées les PCR. Et l'avantage, c'est qu'on peut étendre le PCR en hachant le modèle d'après et de hacher ce H avec le H précédent et ce qui crée finalement une chaîne de confiance parce que si on sait que c'est H, match les valeurs attendues, on sait que uniquement le code qu'on veut, ce qui se soit exécuté, a été exécuté. Donc le TPM va seulement décrypter les clés d'exécution si c'est PCR match, donc ce qui veut dire que le code qu'on veut exécuter est ce qui a été exécuté, ce qui veut dire que si quelqu'un arrive à overrider les parties non protégées en écriture de la ROM, ça changera ces valeurs et le TPM ne donnera pas la clé à eux. Ça prend aussi un mot de passe par l'utilisateur et ce mot de passe est validé par le hardware TPM lui-même, ce qui nous donne une limitation hardware sur le nom de fois qu'un hacker peut essayer un mot de passe ce qui peut fixer une limite de retry parce que le TPM va finalement effacer la clé si le hacker fait trop d'essai renait. Donc ça signifie que maintenant il y a encore une autre manière de perdre la clé des disques qui a la blague sur ceux qui ont des disques en frité c'est qu'il y a deux catégories, ceux qui ont perdu leurs données et ceux qui vont perdre leurs données. Donc ce que ça fait c'est que cette clé est expliqué en différentes pièces mais qui peut être stockée sur différents services qui peut être donné à des amis mais qui peut être utilisé, mises tout ensemble enfin en tant que clinique, elle peut pas être utilisé pour décifrer le disque mais mise ensemble tout peut être utilisé pour recréer la clé d'écription. On espère que maintenant on sait que le système exécute le code qu'on pense qu'il est en train d'expriser mais qu'est-ce que ça prouve que ça va être notre machine qu'il n'y a pas quelqu'un qui est venu dans notre chambre et qui a en fait échangé tout le matériel contre leur propre matériel afin de nous triquer à entrer notre mode base dans un autre ordinateur Certains de ces confiances il y a une clé, enfin une phrase unique qui est encodée dans le matériel On se basant sur le time-based one-time password utilisé par Google pour protéger le firmware et qui atteste l'utilisateur que le firmware n'est pas modifié donc quand le système démarre et passe à travers toutes les différentes étapes le TPM va seulement reliser le secret si ce code est matché On va vous comparer avec le mode sur votre téléphone et ça va dire si c'est possible d'utiliser les mains de la machine C'est une chaine script tricourt pour dire la valeur du TPM et comparer le hash Ça peut aussi aller à une chaine une trust par base sur le TPM mais sur une Ça protège aussi contre une attaque si le vendeur a perdu la clé et le sous-net l'utilise pour attaquer votre machine Le système a une chaine script qui protège contre une rollback aussi avec les valeurs des TPM Ça preuve quand c'est le système d'exploitation qu'on veut démarrer mais aussi la version actuelle avec un niveau de démarrabilité Le fait d'avoir une clé PGP fait aussi que c'est compatible avec Android On hash tous les blocs jusqu'à ce qu'on a un routage dans l'arme de hash pour vérifier l'assignature C'est nécessaire pour le système de route mais nous avons besoin d'une route false une fois qu'on a notre système d'exploitation qui est en train de s'exploiter et de s'assurer comment on peut sécuriser la transition sur un OS Il aime bien les cubes C'est recommandé par les gens qui sont bien au point sur la health point Le team cubes reconnaît que la sécurité du firmware est essentielle Dans l'édition 4 de cubes le système d'exploitation va requérir que le firmware soit un firmware open source tel que Coreboot Il a beaucoup travaillé avec le software cubes et il l'a rendu compatible avec le système Coreboot Le système peut maintenant bloquer la configuration pour que personne ne puisse changer le setup Les builds sont très importants afin qu'on puisse vérifier que les blocs correspondent à ce qu'il y aurait Il y a beaucoup de différences qui ne peuvent pas être reproduites Il a aussi créé des tools qui permettent de créer des RAM disques avec par exemple cubes avec tout leur release sont signés de manière cryptographique Il espère que GitHub ne va pas injecter des patchs Il n'y a pas de NDA Il n'y a pas de requin C'est à peu près l'état actuel dans l'état beta, mais c'est utilisable Il y a beaucoup de domaines où il y a beaucoup de recherche tel que les contrôleurs Il a essayé de porter Coreboot sur des plateformes plus modernes pour supporter des choses Il a essayé de passer Coreboot sur des plateformes serveurs pour qu'on puisse l'utiliser Les serveurs ont un modèle de menace très différent de laptop Il y a beaucoup de choses dans les fermoirs Une des collaborations qu'il a c'est avec le projet OpenDMC Il a aussi le Master OpenCloud qui est un projet qui est très optimiste sur ses collaborations Il a assez optimiste sur ses collaborations Il y a beaucoup de discussions sur GitHub Je serai très heureux pour les contributions donc tout le monde qui s'en a inspiré peut contribuer avec plaisir Si vous êtes intéressé je resterai au Coreboot et pendant cette semaine le team de Coreboot a quelques personnes qui peuvent vous aider à installer Coreboot Cette taux qui peut se trouver sur son site web Merci beaucoup à tout le monde pour venir voir ce projet J'espère que tout le monde est aussi excité C'est quelqu'un des questions Merci Merci beaucoup pour cette taux Vous avez un mot pour les 45% des gens qui sont restés sur des notebooks pas compatibles avec Coreboot ? Oui, achetons un autre laptop En réalité, il y a des institutions qui doivent être restées et qui sont responsables à la fois de la CPI et de les fermoirs Selon votre modèle de menace les détails de fermoirs ne pourraient pas être un grand concern ou alors ça pourrait être un grand souci pour vous ça te ferait sens de revenir à ma première suggestion qui a clippé le Red Protect Pin sur la chipset et enlever physiquement les choses qui pourraient être représentées de menace Est-ce que les processors ARM sont supportés à Coreboot ? ARM a beaucoup d'avantage C'est seulement 20 années plutôt que 40 et le processus de boot sur ARM est beaucoup plus simple comme il n'y a pas besoin de passer à travers le mode réel jusqu'à passer par la pagination et toutes les autres étapes Par contre, le désavantage de beaucoup d'armes c'est que leur code de boot est sur le chip et il contrôle l'utilisateur beaucoup de ce code de boot est relativement simple et peut établir une chaîne de confiance hardware Il y a eu beaucoup de gens qui se posent la question si on peut rendre Coreboot relativement à ARM donc je pense que vous aurez plusieurs réponses dans notre booth Coreboot Alors si Coreboot est en train d'appuyer et qu'il est en train d'appuyer alors si Uboot est possible sur le plate-forme c'est possible aussi C'est un payload pour Coreboot en fait C'est une question de Yossi Coreboot a des blobs d'intel avec les superfounders qu'on est possibles que c'est secure Donc le FSB d'intel et donc le firmware Superth Package qui est requis pour initialiser le contrôle de la firmware sur les CPUs Intel donc sur les plus vieux CPUs tel que le Cyanid Bridge ou Ivy Bridge le Coreboot et les Reboots sont capables d'initialiser la mémoire sans passer pour le FSB Néanmoins quand on regarde ce que Coreboot fait dans le MRC sur ses plate-formes il semblerait qu'il remplisse jusqu'ici avec des valeurs qui fonctionnent et les contrôleurs de mémoire modernes sont tellement complexes qu'ils ne refusent de documenter cela sans des NDAs extensifs que ce qui fait que c'est très dur de construire une décision sur mémoire quelconque mais on ne peut pas dire que c'est un soft à 100% libre mais le FSB est mesuré et invariable avec... même si ça ne nous donne pas 100% d'open source pour autant qu'il le sache le seul système qui fait ça c'est Benizia's Novena Laptop au moins on peut le mesurer et on peut voir que ça n'a pas été modifié par rapport à ce qu'il dit installé initialement c'est un grand projet sur le niveau architecturiel et combinaison de Linux et Shell pourquoi pas BST kernel et pourquoi Shell à part de Python no Askel il y a beaucoup de volonté de supporter Pistole sur le niveau architecturiel il y a beaucoup de volonté de supporter Python mais le problème c'est qu'il y a beaucoup de... l'espace est très limité donc dans le ROM de boot il y a 4 megabytes d'espaces disponibles et l'interprétateur Python fait déjà quelques méga à lui tout seul donc pourquoi Linux plutôt que BSD le system call qui est un composant principal afin de pouvoir faire un shutdown du kernel Linux et de transférer à n'importe quel autre système compliant avec un multi-boot qui a une feature essentielle de leur système donc si BSD avait cette fonctionnalité ça aurait été possible d'utiliser BSD mais dans l'état actuel des choses merci comment est Coreboot mis à jour et le payload si c'est une blob des mesures alors après une mise à jour cette cour va être changée et c'est pas assez plus clair que c'est donc le fait de créer des clés d'inclusion avec les TPN requiert des steps explicites donc il faut un des avantages du build reproductible est que les H avec tous les stages du firmware peuvent être publiés afin qu'on puisse siler les clés avec une nouvelle valeur qui est actuellement en train de travailler sur un minimum un heads encore plus minimal qui intégrerait qu'un driver USB qui permettrait de bouter sur un device et de l'installer sur un autre endroit sur le site web heads et implementés sur un ThinkPad est-ce que c'est très difficile d'implementer sur un autre laptop les ThinkPad sont très populaires dans les comités de sécurité informatique et c'est pour ça que Coreboot était branché au ThinkPad à part des ThinkPad et Chromebooks il n'y a pas beaucoup de devices qui peuvent démarrer à Coreboot on espère que il y a des vendeurs il y a des valeurs d'artwaire pour la communauté open source et comme une mesure de liberté Est-ce que vous avez prévu de retravailler un firmware intégré sur la question était comment est-ce qu'on replace le C avec du firmware open source donc le Chromebook a un NISC open source donc bilder pour un Chromebook donc Chromebook a un protocole très élégant pour tester que le C est en train d'exécuter le firmware qu'on pense qu'il est en train d'exploiter donc beaucoup de chipsets ici ont des communications disponibles pour voir qui explique comment il fonctionne ou si tu as un prototype fonctionnel sur un ThinkPad on peut probablement avoir d'autres j'ai pas compris la suite de la phrase donc si tu as un prototype fonctionnel sur ThinkPad est-ce que tu finiras bientôt avec le Chromebook ou si tu es en train d'exécuter votre travail sur d'autres plateformes c'est que tu prévois d'étendre le travail à d'autres plateformes donc lui il a un keyboard modifié sur son ThinkPad et qu'il a besoin d'un NISC modifié mais c'est toujours encore en recherche du question d'IOC est-ce que SystemD va être utilisé dans le process de boot et est-ce qu'il va être utilisé dans le process de boot et si vous flash le firmware sur le congrès ici avec un programme hardware est-ce que c'est possible après mettre un jour le système ou c'est toujours nécessaire d'avoir un programme hardware maintenant vous pouvez mettre un jour après un grave risque de laisser le flash détruit et plus écrireable Laurent on travaille sur une mise à jour software qui laisse le boot bloc rester immutable et on n'a pas place pour des applications larges comme SystemD merci merci à tous alors c'était notre injection français