Un ordinateur RISC-V 64 bits auto-hébergé, fiable, libre/open source et compatible Linux

 (contrib.andrew.cmu.edu)
1 points par GN⁺ 2024-05-20 | 1 commentaires | Partager sur WhatsApp
  • L’objectif est de créer une pile libre/open source auto-hébergée dont tout le fonctionnement peut être retracé jusqu’à du HDL et du code logiciel publics, et sur laquelle la chaîne d’outils peut elle-même être reconstruite et exécutée
  • Comme il n’est pas possible de fabriquer directement un ASIC, le matériel est déployé sur FPGA, et la génération comme la programmation du bitstream doivent aussi être gérées avec des outils libres/open source
  • L’approche FPGA est considérée comme rendant difficile pour la fonderie de connaître l’usage réel et l’emplacement des bits sensibles, ce qui peut limiter les attaques au stade de la fabrication à un niveau de DoS
  • La structure en grille régulière des FPGA rend l’inspection visuelle destructive, comme le retrait chimique et l’imagerie TEM, plus réaliste que pour un ASIC dédié
  • Le problème de confiance restant consiste à rendre le HDL, les logiciels, les compilateurs et les chaînes d’outils tous compilables à partir de sources ouvertes, afin de réduire le périmètre de vérification à des sources auditables

Conditions pour un ordinateur digne de confiance

  • L’objectif est de construire un ordinateur libre/open source depuis la base, afin que tout le fonctionnement matériel et logiciel puisse être expliqué par du HDL et des sources logicielles publics
  • Le compilateur et les chaînes d’outils associées utilisés pour produire l’ensemble du système doivent eux aussi être libres/open source, et pouvoir être compilés et exécutés sur cet ordinateur
  • Au final, ce qu’il faut est une pile matériel+logiciel libre/open source auto-hébergée
  • Comme il n’est pas possible de posséder ou de contrôler une fonderie de silicium, les composants matériels sont implémentés sur FPGA
  • La programmation du FPGA et la génération du bitstream doivent également être effectuées avec des outils libres/open source pour préserver le modèle de confiance

Le compromis de confiance apporté par le FPGA

  • L’utilisation d’un FPGA est un compromis réaliste choisi au lieu de fabriquer directement un ASIC dédié
    • La fonderie de puces peut difficilement savoir à quoi servira le FPGA, ni où le soi-disant privilege bit sera placé dans la puce
    • Dans ces conditions, les portes dérobées matérielles permettant une élévation de privilèges peuvent être atténuées, et les attaques pouvant être implantées lors de la fabrication du FPGA sont considérées comme limitées au DoS
    • Même si l’ordinateur peut s’arrêter complètement, la probabilité qu’il trahisse son propriétaire tout en semblant fonctionner normalement est jugée plus faible
  • Comme un FPGA possède une structure en grille régulière avec des composants identiques répétés, l’inspection visuelle destructive est considérée comme plus faisable que pour un ASIC dédié
    • Les exemples cités sont le retrait chimique et l’imagerie TEM
  • Même après réduction de la surface d’attaque au stade de la fabrication, des risques comme des sources ou une chaîne d’outils malveillantes subsistent
    • Ce problème est traité en exigeant que l’ensemble du HDL, des logiciels et des chaînes d’outils soient disponibles sous forme de sources publiques compilables

Ressources de référence et expérimentations d’implémentation

À lire aussi

1 commentaires

 
GN⁺ 2024-05-20
Avis de Hacker News

  • En théorie, il pourrait y avoir un CPU caché dans le FPGA, avec peut-être un accès en lecture/écriture à l’ensemble du programme du FPGA
    De plus, si les volumes de production du FPGA augmentent pour le même système ou pour une génération suivante, la fonderie obtiendrait des informations supplémentaires et pourrait assez bien estimer où se trouvent les bits de privilège
    Plus simplement, on pourrait aussi charger du code sur le FPGA pour l’analyser directement

    • De nos jours, ils sont tous construits comme ça. Ce n’est même pas caché
      Si vous achetez un gros FPGA, il contient des cœurs ARM, et tous ces cœurs ARM exécutent en EL3 des blobs signés opaques que l’utilisateur ne peut pas remplacer
      Ce n’est pas un soft core sur la fabric, mais du silicium dédié, et il peut aussi accéder à l’ICAP des puces Xilinx, c’est-à-dire au port d’accès à la configuration interne, ainsi qu’aux fonctionnalités équivalentes chez d’autres fabricants
    • Il me semblerait plus simple de mettre une backdoor dans la RAM
      La DRAM moderne comporte beaucoup de fonctions complexes comme le link training, le refresh ciblé et la correction d’erreurs on-die ; même sans connaître l’implémentation exacte, cette complexité suffit largement à y dissimuler une backdoor
      On pourrait y ajouter une fonction qui surveille certains motifs d’accès mémoire et, lorsqu’elle détecte le bon motif, donne des droits arbitraires de lecture/écriture
      Ainsi, cela pourrait servir à une élévation de privilèges depuis du code non fiable mais sandboxé comme du JavaScript ; avec une lecture mémoire arbitraire permettant de trouver où écrire, cela fonctionnerait indépendamment de l’architecture CPU ou du système d’exploitation
      Ce serait moins efficace avec des DIMM ou des modules mémoire à plusieurs puces, mais les ordinateurs RISC-V sont généralement de petites cartes mono-ordinateur avec une seule puce DRAM
    • Cette approche ressemble au Thompson hack, où un compilateur malveillant possède une backdoor qui se propage d’elle-même
      Elle n’apparaît pas dans le code source, mais s’injecte elle-même dans le binaire
      Thompson l’a démontré dans des conditions contrôlées, mais, dans le monde réel, une telle backdoor devrait faire preuve d’une subtilité proche du niveau d’une AGI pour échapper à la détection
      Elle devrait continuer à fonctionner et à se propager malgré l’évolution du matériel et du logiciel, tout en gardant des traces faibles en taille et en temps d’exécution
      Reconstruire ainsi l’informatique moderne sur des bases complètement différentes gênerait et compliquerait beaucoup l’utilisation de telles backdoors
      https://en.wikipedia.org/wiki/Backdoor_(computing)#Compiler_...
    • Je me demande aussi s’il ne serait pas plus simple d’espionner les E/S et d’exfiltrer les données d’une manière ou d’une autre
      Bien sûr, ce serait totalement irréaliste pour une surveillance de masse à grande échelle, mais si un acteur étatique savait qu’une organisation utilise cette technique pour échapper à la surveillance et que sa configuration logicielle est prévisible, ce serait une autre histoire
    • Même si un tel CPU existait, il serait extrêmement difficile de déterminer quels registres ou quelles portes du FPGA implémentent quels composants du soft CPU
      Le placement n’est pas fixe et il n’existe pas de correspondance cohérente entre les LUT/FF matériels et les fonctions synthétisées

  • C’est vraiment impressionnant de pouvoir se connecter à un shell Linux sur un FPGA orangecrab exécutant un softcore RISC-V construit avec une toolchain open source
    Il n’y a pas si longtemps, c’était impossible ; au mieux, on avait Xilinx PetaLinux et leur fatras propriétaire

    • Ce qui est amusant, c’est que même le FPGA de l’orangecrab n’est pas indispensable
      SERV, et même QERV, tiennent sans problème dans un petit iCE40 LP1K
      C’est étonnant de voir à quel point une implémentation RISC-V entièrement compatible peut être petite
    • Cela va bientôt, je pense, fédérer une communauté
      Le matériel ouvert et le logiciel ouvert fonctionnent enfin ensemble, et cela deviendra un très grand mouvement d’ici dix ans

  • Je vais dans une direction similaire, mais par un chemin différent
    Ma conception est basée sur VexRiscv et tout le matériel est écrit en SpinalHDL
    La SRAM de la carte Karnix étant limitée à 512 Ko, elle ne peut pas encore faire tourner Linux, mais elle dispose d’Ethernet et de HDMI
    J’ai aussi implémenté via l’interface HDMI un adaptateur vidéo de type CGA, avec prise en charge des modes graphique 320x240x4 et texte 80x30x16, ainsi qu’un défilement fluide assisté par matériel
    Si cela vous intéresse, un court README est ici : https://github.com/Fabmicro-LLC/VexRiscvWithKarnix/blob/karn...
    Projet KiCAD pour la carte : https://github.com/Fabmicro-LLC/Karnix_ASB-254

  • Beau travail
    J’ai été content de voir que mes travaux sur la compilation double diversifiée (DDC) contre les attaques trusting trust étaient cités de façon visible
    Si la DDC vous intéresse, voir ici : https://dwheeler.com/trusting-trust

  • Reconstruire le système sur lui-même et vérifier que le bitfile est identique, c’est une bonne chose
    Je suis surpris qu’il puisse être reconstruit avec 512 Mo, et qu’il n’ait fallu « que » 4,5 heures environ sur un CPU à 65 MHz
    D’après mon expérience avec yosys, vivado, etc., j’avais plutôt l’impression qu’il fallait généralement plusieurs Go
    Il était dit qu’un CPU à 65 MHz capable de faire tourner Linux évoque l’Intel 486 du milieu des années 1990 et le Pentium de première génération, mais la combinaison 50–65 MHz et 512 Mo me semble plus proche des stations de travail Unix du début des années 1990
    Côté RAM, on pourrait même dire que c’est mieux
    Pour référence, sur lowRISC/50 MHz, le linpack en double précision atteint 4,5 Mflops

  • En 2022, j’ai fait quelque chose de similaire avec LiteX, mais avec un FPGA Kintex-7, donc, au moins à l’époque, il fallait Vivado pour le placement-routage réel, et ce n’était donc pas auto-hébergé
    Cela a tout de même donné un ordinateur portable à gateware ouvert faisant tourner Linux et Xorg, grâce à Linux-on-LiteX-VexRiscV : https://mntre.com/media/reform_md/2022-09-29-rkx7-showcase.h...

  • Le Shakti, basé sur RISC-V, de l’IIT-Madras en Inde, mérite aussi d’être consulté : Open Source Processor Development Ecosystem - https://shakti.org.in/
    L’aperçu de Wikipédia est également utile : https://en.wikipedia.org/wiki/SHAKTI_(microprocessor)

  • C’est aussi la personne qui avait travaillé à l’époque sur l’exécution d’OS X sous qemu/kvm : https://www.contrib.andrew.cmu.edu/~somlo/OSXKVM/

  • Vraiment impressionnant
    Cela fait un moment que je pense qu’on a cruellement besoin d’une machine RISC-V entièrement auto-hébergée
    Pour l’instant, la plus grosse contrainte semble être de trouver une carte FPGA avec suffisamment de RAM embarquée
    La carte visée ici semble avoir 512 Mo, mais les toolchains FPGA sont généralement bien plus à l’aise quand elles peuvent utiliser plusieurs Go

  • J’aime l’idée d’un matériel et d’un logiciel auto-hébergés, mais je n’ose même pas imaginer la douleur de compiler quelque chose comme GCC sur un CPU à 60 MHz
    En plus, le CPU Rocket est écrit en Scala
    J’ai récemment arrêté d’utiliser Gentoo sur un RockPro64, parce que les temps de compilation étaient intenables
    Et ce système est plus rapide de plusieurs ordres de grandeur que celui envisagé ici

    • On peut le rendre beaucoup plus rapide
      Beaucoup de ces cœurs libres et open source sont soit très peu optimisés, soit pensés pour des ASIC, ce qui donne des performances très médiocres sur FPGA
      Avec un cœur bien conçu sur un FPGA moderne — pas sur ces composants Lattice très bas de gamme et basse consommation — il est tout à fait possible d’atteindre 250 MHz ou plus avec une microarchitecture plus robuste
      Mais ce n’est ni bon marché ni facile, donc on le voit rarement dans le domaine amateur
      Et les meilleurs FPGA n’ont souvent pas de toolchain libre et open source, ce qui cadre moins bien avec l’esprit du logiciel libre
      Cela dit, même à 250 MHz, faire tourner Chipyard sur un softcore resterait un exercice de patience
    • Autrefois, on travaillait réellement sur des systèmes SPARC à 50 MHz, avec des périphériques eux aussi bien plus lents, comme de l’Ethernet à 10 Mbps et des disques SCSI lents, et avec moins de RAM, plus lente
      J’admets toutefois que compiler tout ce qu’on veut pourrait prendre une semaine
      Bien sûr, il reste aussi la compilation croisée
    • Certains se souviennent encore de ce que ça fait de compiler quelque chose comme GCC sur un CPU à 60 MHz
      Ce n’est pas si vieux
    • Il fut un temps où avoir un ordinateur tournant aussi vite que 60 MHz était un rêve
      Mes premiers ordinateurs tournaient autour de 1 MHz
      Sur une machine lente, la compilation prendra plus de temps, mais ce n’est pas un gros problème en soi
      Si l’ordinateur est stable et que les scripts de build sont corrects, il suffit de le laisser tourner pendant des jours ou des semaines
      Dans ma vie, j’ai lancé beaucoup de tâches qui prenaient des jours ou des semaines
      Voir « compiling » : https://xkcd.com/303/
      Le vrai problème, c’est le débogage
      Déboguer sur un système lent peut être pénible, car les cycles d’itération deviennent longs
      Historiquement, on résolvait cela en découpant le processus en étapes et en permettant de reprendre à plusieurs points, afin de ne pas tout relancer depuis le début à chaque fois
      La même méthode fonctionne ici
      Autre option : déboguer les scripts sur un système plus rapide mais moins fiable, puis, une fois leur fonctionnement vérifié, les exécuter sur le système lent