Ordinateur auto-hébergé 64 bits RISC-V fiable, gratuit et compatible Linux
(contrib.andrew.cmu.edu)Ordinateur auto-hébergé 64 bits RISC-V fiable, libre et compatible Linux
Motivation
-
Objectif : construire un ordinateur Free/OpenSource entièrement digne de confiance
- Tous les comportements du matériel et du système logiciel proviennent exclusivement d’un HDL (langage de description matériel) entièrement public et des sources logicielles
- Le compilateur et la toolchain associée doivent également être Free/OpenSource, et pouvoir être compilés et exécutés sur ce système informatique
- En d’autres termes, une pile matérielle + logicielle Free/OpenSource auto-hébergée est nécessaire
-
Contraintes : ne pas posséder ni contrôler de fonderie de silicium
- Comme il n’est pas possible de fabriquer son propre ASIC, les composants « matériels » seront construits sur FPGA
- La programmation du FPGA et la génération du bitstream seront réalisées avec des outils Free/OpenSource
-
Avantages du point de vue de la confiance :
- La fonderie ne peut pas savoir à quoi le FPGA sera utilisé, ni où des « bits privilégiés » seraient placés dans la puce
- Cela aide à prévenir les portes dérobées matérielles permettant une élévation de privilèges
- Les FPGA sont constitués d’une grille régulière de composants identiques, ce qui facilite leur inspection visuelle (décapsulation chimique et imagerie TEM) par rapport à un ASIC dédié
-
Réduction de la surface d’attaque lors de la fabrication :
- En limitant les sources malveillantes potentielles et/ou la toolchain aux seules sources compilables, on obtient un produit final digne de confiance (un ordinateur matériel + logiciel déployé)
Ressources complémentaires et premières expérimentations
-
Article, diapositives et présentation CReSCT 2020 : citation IEEE S&P 2020
-
Jeu de diapositives et présentation de la revue de recherche CMU/SEI 2019
-
Ancien jeu de diapositives sur les travaux en informatique de confiance au CERT/SEI
-
Projet lowRISC :
- Effort pour rebaser les composants sur leurs projets amont respectifs
- Ce projet a été une ressource très utile et a grandement aidé à comprendre les composants
- Cependant, au moment de la rédaction, il dépend d’une toolchain HDL fermée et utilise des modules IP propriétaires dans sa nomenclature (contrôleur DRAM, etc.)
-
yoloRISC :
- SoC de démonstration blinky basé sur Rocket-Chip, RV64IMAC
- Construit avec yosys/trellis/nextpnr pour la carte de développement Lattice ECP5 5G Versa
L’avis de GN⁺
- Matériel et logiciel libres : ce projet est une tentative de construire un matériel et un logiciel entièrement libres et open source, ce qui le rend très attractif pour les utilisateurs attachés à la fiabilité et à la transparence.
- Avantages des FPGA : l’utilisation de FPGA permet de prévenir les portes dérobées matérielles et d’améliorer la fiabilité grâce à l’inspection visuelle.
- Toolchain et modules IP : aujourd’hui, de nombreux projets dépendent encore de toolchains fermées et de modules IP propriétaires, ce qui complique la recherche d’un environnement totalement open source.
- Défi technique : construire une pile matérielle + logicielle Free/OpenSource auto-hébergée est une tâche extrêmement difficile sur le plan technique.
- Potentiel futur : ce projet peut contribuer de manière importante au développement de futurs systèmes informatiques de confiance et avoir un impact majeur sur la communauté open source.
1 commentaires
Avis Hacker News
Résumé d’un ensemble de commentaires Hacker News
Sécurité des FPGA : il est possible d’empêcher l’implantation de portes dérobées matérielles lors du processus de fabrication des FPGA. Le système peut s’arrêter complètement, mais il ne trahira pas son propriétaire en faisant semblant de fonctionner normalement.
Risques potentiels des FPGA : un CPU caché pourrait se trouver dans le FPGA, avec un accès complet en lecture/écriture au programme du FPGA. Si le système devient populaire, il sera plus probable d’obtenir davantage d’informations sur le processus de fabrication et de trouver des bits privilégiés.
Utilisation d’une toolchain open source : il est surprenant de pouvoir se connecter à un shell Linux sur un FPGA OrangeCrab exécutant un softcore RISV-V avec une toolchain open source. C’était impossible autrefois.
VexRiscv et SpinalHDL : utilisation d’un design basé sur VexRiscv et SpinalHDL qui, en raison d’une SRAM limitée (512 KB), n’exécute pas Linux mais prend en charge Ethernet et HDMI. Un adaptateur vidéo similaire au CGA a été codé pour gérer les modes graphique et texte.
DDC et attaque sur la confiance : satisfaction de voir une référence au travail visant à prévenir les attaques sur la confiance via le diverse double-compiling (DDC). Si le sujet vous intéresse, il est recommandé de consulter les liens associés.
Reconstruction du système : il est recommandé de reconstruire soi-même le système et de vérifier que le bitfile est identique. Le fait qu’une reconstruction soit possible en 4,5 heures avec 512 MB et un CPU à 65 MHz est surprenant.
Comparaison avec les premières stations de travail Unix : 50-65 MHz et 512 MB sont comparables aux stations de travail Unix du début des années 1990. Du point de vue de la RAM, cela pourrait même être meilleur.
LiteX et FPGA Kintex-7 : un travail similaire a été réalisé en 2022 avec LiteX, mais le FPGA Kintex-7 nécessitait Vivado. Le résultat a été la création d’un ordinateur portable à gateware ouvert exécutant Linux et Xorg.
Projet Shakti : recommandation de consulter le projet Shakti, un écosystème de développement de processeurs open source basé sur RISC-V, développé à l’IIT-Madras en Inde.
Travail sur OSXKVM : ce projet est mené par la même personne que celle qui a travaillé à l’exécution d’OSX sur QEMU/KVM.
Nécessité d’une machine RISC-V auto-hébergée : avis selon lequel une machine RISC-V entièrement auto-hébergée est nécessaire. À l’heure actuelle, le principal facteur limitant est de trouver une carte FPGA disposant de suffisamment de RAM.
Difficulté de l’auto-hébergement : l’idée d’un matériel et de logiciels auto-hébergés est bonne, mais construire quelque chose comme GCC sur un CPU à 60 MHz est incroyablement difficile à imaginer. Une expérience est partagée sur l’utilisation de Gentoo sur un RockPro64, abandonnée à cause de temps de compilation trop longs.