Vertrauenswürdiger freier/Open-Source Linux-fähiger 64-Bit-RISC-V-Self-Hosting-Computer

 (contrib.andrew.cmu.edu)
1 Punkte von GN⁺ 2024-05-20 | 1 Kommentare | Auf WhatsApp teilen
  • Ziel ist es, einen self-hosting freien/Open-Source-Stack zu schaffen, dessen vollständiges Verhalten sich bis zu offengelegtem HDL und Software-Quellen zurückverfolgen lässt und auf dem sogar die Toolchain erneut gebaut und ausgeführt werden kann
  • Da eine eigene ASIC-Fertigung nicht möglich ist, wird die Hardware auf FPGA umgesetzt, und auch Bitstream-Erzeugung sowie Programmierung müssen mit freien/Open-Source-Werkzeugen erfolgen
  • Der Einsatz von FPGA erschwert es der Foundry, den tatsächlichen Einsatzzweck und die sensible Bitplatzierung zu erkennen, wodurch Angriffe in der Fertigungsphase auf das DoS-Niveau begrenzt werden können
  • FPGA mit ihrer regelmäßigen Gitterstruktur eignen sich eher für destruktive visuelle Inspektionen wie chemisches Abtragen und TEM-Bildgebung als dedizierte ASICs
  • Das verbleibende Vertrauensproblem besteht darin, HDL, Software, Compiler und Toolchain vollständig aus offenem Quellcode baubar zu machen, um den Prüfungsumfang auf auditierbaren Source Code einzugrenzen

Bedingungen für einen vertrauenswürdigen Computer

  • Ziel ist es, von Grund auf einen freien/Open-Source-Computer aufzubauen, dessen vollständiges Hardware- und Softwareverhalten durch offengelegten HDL- und Software-Quellcode erklärbar ist
  • Auch die Compiler und zugehörigen Toolchains, die das Gesamtsystem erzeugen, müssen frei/Open Source sein und auf diesem Computer selbst gebaut und ausgeführt werden können
  • Erforderlich ist damit ein self-hosting freier/Open-Source-Hardware- und Software-Stack
  • Da man keine Silizium-Foundry besitzt oder kontrolliert, werden die Hardware-Komponenten auf FPGA implementiert
  • Auch FPGA-Programmierung und Bitstream-Erzeugung müssen mit freien/Open-Source-Werkzeugen erfolgen, damit das Vertrauensmodell erhalten bleibt

Der Zuverlässigkeits-Kompromiss von FPGA

  • Der Einsatz von FPGA ist ein realistischer Kompromiss statt der direkten Herstellung eines dedizierten ASIC
    • Für die Chip-Foundry ist schwer erkennbar, wofür ein FPGA verwendet wird oder wo sogenannte privilege bits im Chip angeordnet sind
    • Unter diesen Bedingungen lassen sich Hardware-Backdoors zur Rechteausweitung abschwächen, und Angriffe, die sich in der FPGA-Fertigung einschleusen lassen, gelten als auf DoS beschränkt
    • Der Computer kann zwar vollständig ausfallen, aber es ist weniger wahrscheinlich, dass er scheinbar normal funktioniert und dabei seinen Eigentümer verrät
  • FPGA besitzen eine regelmäßige Gitterstruktur mit sich wiederholenden identischen Komponenten, wodurch destruktive visuelle Inspektionen eher praktikabel sind als bei dedizierten ASICs
    • Beispiele sind chemisches Abtragen und TEM-Bildgebung
  • Auch nach der Reduzierung der Angriffsfläche in der Fertigungsphase bleiben Risiken wie bösartiger Quellcode oder kompromittierte Toolchains bestehen
    • Dieses Problem wird dadurch adressiert, dass für sämtliches HDL, alle Software und alle Toolchains baubarer offener Quellcode verlangt wird

Referenzen und Implementierungsexperimente

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-05-20
Meinungen auf Hacker News

  • Theoretisch könnte es eine in einem FPGA versteckte CPU geben, die außerdem Lese-/Schreibzugriff auf das gesamte FPGA-Programm hat.
    Wenn zudem die FPGA-Produktion für dasselbe System oder die nächste Generation steigt, bekommt die Foundry zusätzliche Informationen und kann ziemlich gut abschätzen, wo die Privilege-Bits liegen.
    Noch einfacher wäre es, Code auf das FPGA zu laden und ihn direkt zu analysieren.

    • Heute ist das alles genau so aufgebaut. Es ist nicht einmal versteckt.
      Wenn man ein großes FPGA kauft, sind ARM-Cores enthalten, und diese ARM-Cores führen alle in EL3 einen undurchsichtigen, signierten Blob aus, den Nutzer nicht ersetzen können.
      Das ist kein Soft-Core auf dem Fabric, sondern dediziertes Silizium, und es hat Zugriff auf ICAP, also den internen Configuration Access Port von Xilinx-Geräten, sowie auf entsprechende Funktionen anderer Hersteller.
    • Es wäre vermutlich einfacher, eine Backdoor im RAM unterzubringen.
      Moderne DRAMs haben viele komplexe Funktionen wie Link Training, Targeted Refresh und On-Die-Fehlerkorrektur; selbst ohne die genaue Implementierung zu kennen, ist da genug Komplexität, um eine Backdoor zu verstecken.
      Man könnte eine Funktion einbauen, die bestimmte Speicherzugriffsmuster überwacht und, wenn das richtige Muster erkannt wird, beliebige Lese-/Schreibrechte bereitstellt.
      Damit ließe sich aus nicht vertrauenswürdigem, aber sandboxed Code wie JavaScript eine Privilege Escalation durchführen; da man per beliebigem Speicherlesen die Schreibposition finden kann, könnte das unabhängig von CPU-Architektur oder Betriebssystem funktionieren.
      Bei DIMMs oder Speichermodulen mit mehreren Chips wäre das weniger effektiv, aber RISC-V-Computer sind meist kleine Single-Board-Computer mit nur einem DRAM-Chip.
    • Dieser Ansatz ähnelt dem Thompson Hack, bei dem ein bösartiger Compiler eine sich selbst weiterverbreitende Backdoor enthält.
      Im Source Code taucht sie nicht auf, wird aber selbstständig in das Binary injiziert.
      Thompson hat das unter kontrollierten Bedingungen demonstriert, aber in der Praxis müsste eine solche Backdoor, um der Entdeckung zu entgehen, nahezu AGI-artig raffiniert sein.
      Sie müsste weiter funktionieren und sich weiterverbreiten, während sich Hardware und Software entwickeln, und zugleich Spuren wie Größe oder Laufzeit dauerhaft gering halten.
      Moderne Computertechnik auf einer völlig anderen Grundlage neu aufzubauen, würde den Einsatz solcher Backdoors erheblich erschweren und verkomplizieren.
      https://en.wikipedia.org/wiki/Backdoor_(computing)#Compiler_...
    • Ich frage mich auch, ob es nicht einfacher wäre, I/O mitzulesen und Daten irgendwie herauszuschleusen.
      Für massenhafte anlasslose Überwachung wäre das natürlich völlig unrealistisch, aber wenn ein staatlicher Akteur weiß, dass eine Organisation diese Technik nutzt, um Überwachung zu entgehen, und die Softwarekonfiguration vorhersehbar ist, könnte die Sache anders aussehen.
    • Selbst wenn es eine solche CPU gäbe, wäre es extrem schwierig herauszufinden, welche Register oder Gates auf dem FPGA welche Komponenten der Soft-CPU implementieren.
      Das Placement ist nicht fest, und es gibt kein konsistentes Mapping zwischen Hardware-LUTs/FFs und der synthetisierten Funktion.

  • Es ist wirklich erstaunlich, dass man sich per Linux-Shell auf einem orangecrab-FPGA einloggen kann, auf dem ein mit einer Open-Source-Toolchain gebauter RISC-V-Softcore läuft.
    Vor gar nicht langer Zeit war das unmöglich; bestenfalls gab es Xilinx PetaLinux und deren proprietären Kram.

    • Interessant ist, dass selbst das FPGA des orangecrab nicht zwingend nötig ist.
      Selbst in ein kleines iCE40 LP1K passen SERV und sogar QERV problemlos hinein.
      Es ist erstaunlich, wie klein eine vollständig kompatible RISC-V-Implementierung werden kann.
    • Das dürfte bald ein Anlass sein, um die Community zusammenzubringen.
      Open Hardware und Open Software funktionieren endlich gemeinsam, und innerhalb von zehn Jahren wird daraus eine sehr große Bewegung werden.

  • Ich gehe in eine ähnliche Richtung, aber auf einem anderen Weg.
    Mein Design basiert auf VexRiscv, und die gesamte Hardware ist in SpinalHDL geschrieben.
    Wegen der auf 512 KB begrenzten SRAM des Karnix-Boards läuft darauf noch kein Linux, aber es hat Ethernet und HDMI.
    Außerdem habe ich über das HDMI-Interface einen CGA-ähnlichen Video-Adapter implementiert, der Grafikmodi mit 320x240x4 und Textmodi mit 80x30x16 sowie hardwareunterstütztes sanftes Scrollen unterstützt.
    Wer Interesse hat: Ein kurzes README gibt es hier: https://github.com/Fabmicro-LLC/VexRiscvWithKarnix/blob/karn...
    KiCAD-Projekt für das Board: https://github.com/Fabmicro-LLC/Karnix_ASB-254

  • Tolle Arbeit.
    Ich habe mich gefreut, dass meine Arbeit zu Diverse Double-Compiling (DDC) als Gegenmaßnahme gegen trusting-trust-Angriffe prominent zitiert wurde.
    Wer sich für DDC interessiert, findet hier mehr: https://dwheeler.com/trusting-trust

  • Es ist gut, das System auf sich selbst neu zu bauen und zu verifizieren, dass das Bitfile identisch ist.
    Erstaunlich ist, dass der Rebuild mit 512 MB möglich ist und auf einer CPU mit rund 65 MHz „nur“ 4,5 Stunden gedauert hat.
    Aus Erfahrung mit yosys, vivado und Ähnlichem hatte ich eher den Eindruck, dass dafür normalerweise mehrere GB nötig sind.
    Es wurde gesagt, eine Linux-fähige 65-MHz-CPU erinnere an Intel 486 und die erste Pentium-Generation der mittleren 1990er, aber die Kombination aus 50–65 MHz und 512 MB wirkt eher wie eine Unix-Workstation der frühen 1990er.
    Beim RAM kann man sogar sagen, dass sie eher besser dasteht.
    Zum Vergleich: Auf lowRISC/50MHz erreicht Double-Precision-Linpack 4,5 Mflops.

  • 2022 habe ich etwas Ähnliches mit LiteX ausprobiert, aber mit einem Kintex-7-FPGA; zumindest damals war für das tatsächliche Place-and-Route Vivado nötig, daher war es nicht selbst gehostet.
    Trotzdem entstand daraus ein Open-Gateware-Laptop, auf dem Linux und Xorg liefen, dank Linux-on-LiteX-VexRiscV: https://mntre.com/media/reform_md/2022-09-29-rkx7-showcase.h...

  • Ebenfalls einen Blick wert ist das RISC-V-basierte Shakti des IIT Madras in Indien: Open Source Processor Development Ecosystem – https://shakti.org.in/
    Auch die Übersicht auf Wikipedia ist gut: https://en.wikipedia.org/wiki/SHAKTI_(microprocessor)

  • Das ist derselbe, der früher auch an OS X unter qemu/kvm gearbeitet hat: https://www.contrib.andrew.cmu.edu/~somlo/OSXKVM/

  • Wirklich großartig
    Ich denke schon seit einer Weile, dass wir dringend eine vollständig selbst gehostete RISC-V-Maschine brauchen
    Die größte Einschränkung scheint derzeit zu sein, ein FPGA-Board mit genügend Onboard-RAM zu finden
    Das hier anvisierte Board scheint 512 MB zu haben, aber FPGA-Toolchains fühlen sich normalerweise deutlich wohler, wenn sie ein paar GB nutzen können

  • Die Idee selbst gehosteter Hardware und Software ist gut, aber ich kann mir den Schmerz nicht vorstellen, auf einer 60-MHz-CPU so etwas wie GCC zu bauen
    Außerdem ist die Rocket CPU in Scala geschrieben
    Ich habe kürzlich aufgehört, Gentoo auf einem RockPro64 zu verwenden, weil die Compile-Zeiten unerträglich waren
    Dieses System ist auch um mehrere Größenordnungen schneller als das, was hier verwendet werden soll

    • Man kann es deutlich schneller machen
      Viele dieser freien Open-Source-Cores sind entweder überhaupt nicht gut optimiert oder zielen auf ASICs ab und liefern auf FPGAs sehr schlechte Performance
      Mit einem gut entworfenen Core auf einem modernen FPGA sind, sofern es nicht so ein Low-End-Low-Power-Bauteil von Lattice ist, mit einer stärkeren Mikroarchitektur durchaus 250 MHz oder mehr möglich
      Allerdings ist das weder billig noch einfach, weshalb man es im Hobbybereich kaum sieht
      Außerdem gibt es für bessere FPGAs oft keine freie Open-Source-Toolchain, was auch nicht gut zum Geist freier Software passt
      Trotzdem dürfte es selbst bei 250 MHz auf einem Softcore eine Geduldsübung werden, Chipyard laufen zu lassen
    • Früher hat man mit 50-MHz-SPARC-Systemen echte Arbeit erledigt; auch die Peripherie war mit 10-Mbps-Ethernet und langsamen SCSI-Laufwerken viel langsamer, und RAM gab es weniger und langsamer
      Ich stimme allerdings zu, dass es eine Woche dauern könnte, alles zu kompilieren, was man möchte
      Natürlich gibt es auch die Möglichkeit des Cross-Compiling
    • Manche erinnern sich noch daran, wie es sich anfühlt, auf einer 60-MHz-CPU so etwas wie GCC zu bauen
      So lange ist das noch gar nicht her
    • Es gab einmal eine Zeit, in der es ein Traum war, einen Computer zu besitzen, der so schnell wie 60 MHz lief
      Die ersten Computer, die ich benutzt habe, liefen ungefähr mit 1 MHz
      Auf langsamen Maschinen dauert das Kompilieren länger, aber das ist an sich kein großes Problem
      Wenn der Computer stabil ist und die Build-Skripte stimmen, lässt man ihn einfach ein paar Tage oder Wochen laufen
      Ich habe in meinem Leben viele Jobs laufen lassen, die Tage oder Wochen dauerten
      Siehe „compiling“: https://xkcd.com/303/
      Das eigentliche Problem ist Debugging
      Debugging auf einem langsamen System kann wegen der langen Iterationszyklen quälend sein
      Historisch hat man das gelöst, indem man die Schritte aufgeteilt und es möglich gemacht hat, an mehreren Punkten neu zu starten, damit nicht jedes Mal der gesamte Prozess wiederholt werden muss
      Derselbe Ansatz funktioniert auch hier
      Zusätzlich gibt es die Option, Skripte auf einem schnelleren, aber weniger vertrauenswürdigen System zu debuggen und sie dann, sobald ihr Verhalten bestätigt ist, auf dem langsamen System auszuführen