Computadora RISC-V de 64 bits autoalojada, confiable, libre/de código abierto y compatible con Linux

 (contrib.andrew.cmu.edu)
1 puntos por GN⁺ 2024-05-20 | 1 comentarios | Compartir por WhatsApp
  • El objetivo es crear una pila libre/de código abierto autoalojada, en la que todo el comportamiento pueda rastrearse hasta HDL y código fuente de software públicos, y en la que incluso el toolchain se reconstruya y ejecute sobre ese mismo sistema
  • Como no es posible fabricar un ASIC propio, el hardware se monta sobre FPGA, y la generación y programación del bitstream también deben realizarse con herramientas libres/de código abierto
  • Se considera que el enfoque con FPGA dificulta que la foundry conozca el uso real y la ubicación de bits sensibles, lo que puede limitar los ataques en la etapa de fabricación a nivel de DoS
  • En un FPGA, con su estructura regular de grilla, la inspección visual destructiva, como la remoción química y la obtención de imágenes TEM, resulta más viable que en un ASIC dedicado
  • El problema de confianza restante consiste en hacer que el HDL, el software, el compilador y el toolchain puedan compilarse completamente desde fuentes abiertas, reduciendo el alcance de verificación a fuentes auditables

Condiciones para una computadora confiable

  • El objetivo es construir desde cero una computadora libre/de código abierto, de modo que todo el comportamiento del hardware y el software pueda explicarse mediante HDL y código fuente de software públicos
  • El compilador y el toolchain relacionado que crean todo el sistema también deben ser libres/de código abierto, y deben poder compilarse y ejecutarse sobre esa computadora
  • En consecuencia, lo que se necesita es una pila de hardware+software libre/de código abierto autoalojada
  • Como no se posee ni se controla una foundry de silicio, los componentes de hardware se implementan sobre FPGA
  • La programación del FPGA y la generación del bitstream también deben manejarse con herramientas libres/de código abierto para mantener el modelo de confianza

Compromisos de confiabilidad que ofrece el FPGA

  • El uso de FPGA es un compromiso práctico elegido en lugar de fabricar directamente un ASIC dedicado
    • A la foundry del chip le resulta difícil saber para qué se usará el FPGA o dónde se ubicará dentro del chip el llamado privilege bit
    • Bajo estas condiciones, se considera que se pueden mitigar backdoors de hardware para escalada de privilegios, y que los ataques que pueden insertarse durante la fabricación del FPGA quedan limitados a DoS
    • La evaluación es que la computadora podría detenerse por completo, pero sería menos probable que traicione a su dueño mientras aparenta funcionar normalmente
  • Como los FPGA tienen una estructura regular de grilla con componentes repetidos, se considera que la inspección visual destructiva es más viable que en un ASIC dedicado
    • Los ejemplos son la remoción química y la obtención de imágenes TEM
  • Incluso después de reducir la superficie de ataque en la etapa de fabricación, permanecen riesgos como fuentes maliciosas o toolchains comprometidos
    • Este problema se aborda exigiendo que todo el HDL, el software y los toolchains estén disponibles como fuentes públicas compilables

Referencias y experimentos de implementación

Lecturas relacionadas

1 comentarios

 
GN⁺ 2024-05-20
Opiniones de Hacker News

  • En teoría podría haber una CPU oculta dentro del FPGA, y también podría tener acceso de lectura/escritura a todo el programa del FPGA.
    Además, si aumenta la producción de FPGA para el mismo sistema o para la siguiente generación, la fundición obtiene información adicional y puede estimar bastante bien dónde están los bits de privilegio.
    Más simple todavía: también se podría cargar código en el FPGA y analizarlo directamente.

    • Hoy en día todos tienen esa arquitectura. Ni siquiera está oculta.
      Si compras un FPGA grande, trae núcleos ARM, y todos esos núcleos ARM ejecutan en EL3 blobs opacos firmados que el usuario no puede reemplazar.
      No es un soft core sobre la fabric, sino silicio dedicado, y puede acceder al ICAP de los dispositivos Xilinx, es decir, al puerto interno de acceso a la configuración, así como a las funciones equivalentes de otros fabricantes.
    • Me parece que sería más fácil meter una puerta trasera en la RAM.
      La DRAM moderna tiene muchas funciones complejas, como link training, refresh dirigido y corrección de errores on-die, y aunque no se conozca la implementación exacta, hay suficiente complejidad como para ocultar una puerta trasera.
      Se podría agregar una función que vigile patrones específicos de acceso a memoria y, cuando detecte el patrón correcto, otorgue permisos arbitrarios de lectura/escritura.
      Así podría usarse para escalar privilegios desde código no confiable pero aislado en sandbox, como JavaScript, y como con lecturas arbitrarias de memoria se puede encontrar dónde escribir, podría funcionar independientemente de la arquitectura de CPU o del sistema operativo.
      Sería menos efectivo en DIMM o módulos de memoria con varios chips, pero una computadora RISC-V suele ser una pequeña computadora de placa única con un solo chip DRAM.
    • Este método se parece al hack de Thompson, en el que un compilador malicioso tiene una puerta trasera que se propaga a sí misma.
      No aparece en el código fuente, pero se inyecta sola en el binario.
      Thompson lo demostró en condiciones controladas, pero en la práctica, para que una puerta trasera así evite ser detectada, se necesitaría una sutileza casi del nivel de una AGI.
      Tendría que seguir funcionando y propagándose aunque el hardware y el software evolucionen, y también mantener siempre bajas huellas como el tamaño o el tiempo de ejecución.
      Reconstruir la computación moderna sobre una base completamente distinta de esta manera dificultaría y complicaría mucho el uso de este tipo de puertas traseras.
      https://en.wikipedia.org/wiki/Backdoor_(computing)#Compiler_...
    • También me pregunto si no sería más fácil espiar el I/O y de alguna forma exfiltrar datos.
      Claro que sería totalmente inviable para vigilancia masiva a gran escala, pero la historia podría ser distinta si un actor estatal sabe que una organización usa esta técnica para evadir la vigilancia y que su configuración de software también es predecible.
    • Incluso si existiera una CPU así, sería extremadamente difícil averiguar qué registro o compuerta sobre el FPGA implementa qué componente de la CPU soft.
      La colocación no es fija y no hay un mapeo consistente entre las LUT/FF de hardware y las funciones sintetizadas.

  • Es realmente sorprendente poder iniciar sesión en un shell de Linux en un FPGA orangecrab que corre un softcore RISC-V construido con un toolchain open source.
    Hasta hace poco era imposible; en el mejor de los casos era Xilinx PetaLinux y su montón de cosas propietarias.

    • Lo interesante es que ni siquiera el FPGA de orangecrab es indispensable.
      En un iCE40 LP1K pequeño también entran SERV, e incluso QERV, sin problemas.
      Es sorprendente lo pequeña que puede llegar a ser una implementación RISC-V totalmente compatible.
    • Siento que pronto esto va a ser un punto de encuentro para la comunidad.
      El hardware abierto y el software abierto por fin están funcionando juntos, y en menos de 10 años será una corriente muy importante.

  • Voy en una dirección parecida, pero por otro camino.
    Mi diseño está basado en VexRiscv y todo el hardware está escrito en SpinalHDL.
    Como la SRAM de la placa Karnix está limitada a 512 KB, todavía no puede correr Linux, pero tiene Ethernet y HDMI.
    También implementé, con interfaz HDMI, un adaptador de video parecido a CGA que admite modos gráficos 320x240x4 y texto 80x30x16, con desplazamiento suave asistido por hardware.
    Si te interesa, aquí hay un README breve: https://github.com/Fabmicro-LLC/VexRiscvWithKarnix/blob/karn...
    Proyecto KiCAD para la placa: https://github.com/Fabmicro-LLC/Karnix_ASB-254

  • Gran trabajo.
    Me dio gusto ver citada de forma destacada mi labor sobre compilación doble diversa (DDC) para contrarrestar ataques de trusting trust.
    Si te interesa DDC, consulta aquí: https://dwheeler.com/trusting-trust

  • Está bien reconstruir el sistema sobre sí mismo y verificar que el bitfile sea idéntico.
    Me sorprende que pueda reconstruirse con 512 MB, y que en una CPU de unos 65 MHz haya tomado “apenas” 4,5 horas.
    Por mi experiencia con yosys, vivado y similares, normalmente parecen requerir varios GB.
    Se decía que una CPU capaz de correr Linux a 65 MHz recuerda a los Intel 486 de mediados de los 90 y a los Pentium de primera generación, pero la combinación de 50–65 MHz y 512 MB se parece más a una workstation Unix de principios de los 90.
    En cuanto a la RAM, incluso podría decirse que es mejor.
    Como referencia, en lowRISC/50 MHz, linpack de doble precisión da 4,5 Mflops.

  • En 2022 hice algo parecido con LiteX, pero usé un FPGA Kintex-7, así que, al menos en ese momento, se necesitaba Vivado para el place & route real, por lo que no era self-hosted.
    Aun así salió una laptop con gateware abierto que corre Linux y Xorg, gracias a Linux-on-LiteX-VexRiscV: https://mntre.com/media/reform_md/2022-09-29-rkx7-showcase.h...

  • También vale la pena consultar Shakti, basado en RISC-V, del IIT-Madras de India: Open Source Processor Development Ecosystem - https://shakti.org.in/
    El resumen de Wikipedia también es bueno: https://en.wikipedia.org/wiki/SHAKTI_(microprocessor)

  • Esta es la misma persona que antes trabajó en temas relacionados con ejecutar OS X en qemu/kvm: https://www.contrib.andrew.cmu.edu/~somlo/OSXKVM/

  • Realmente genial
    Desde hace tiempo pienso que hace mucha falta una máquina RISC-V completamente autoalojada
    Ahora mismo, la mayor limitación parece ser encontrar una placa FPGA con suficiente RAM integrada
    La placa objetivo aquí parece tener 512 MB, pero las toolchains de FPGA normalmente se sienten mucho más cómodas cuando pueden usar varios GB

  • Me gusta la idea de hardware y software autoalojados, pero ni me imagino el dolor de compilar algo como GCC en un CPU de 60 MHz
    Además, el CPU Rocket está escrito en Scala
    Hace poco dejé de usar Gentoo en una RockPro64 porque los tiempos de compilación eran insoportables
    Ese sistema también es varios órdenes de magnitud más rápido que lo que se pretende usar aquí

    • Se puede hacer mucho más rápido
      Muchos de estos núcleos libres y de código abierto directamente están poco optimizados, o están pensados para ASIC, por lo que en FPGA terminan rindiendo muy mal
      Con un núcleo bien diseñado en un FPGA moderno, si no se trata de estos componentes Lattice de gama bajísima y bajo consumo, es perfectamente posible superar los 250 MHz con una microarquitectura más potente
      Solo que no es barato ni fácil, por eso casi no se ve en el ámbito hobby
      Además, los FPGA mejores muchas veces no tienen toolchains libres y de código abierto, así que tampoco encajan muy bien con el espíritu del software libre
      Aun así, incluso a 250 MHz, correr Chipyard en un softcore sería un ejercicio de paciencia
    • Antes se hacía trabajo real con sistemas SPARC de 50 MHz, y los periféricos también eran mucho más lentos, como Ethernet de 10 Mbps y discos SCSI lentos, con menos RAM y más lenta
      Eso sí, coincido en que compilar todo lo que uno quiere podría tomar una semana
      Por supuesto, también existe la opción de la compilación cruzada
    • Hay gente que recuerda cómo se sentía compilar algo como GCC en un CPU de 60 MHz
      Tampoco fue hace tanto tiempo
    • Hubo una época en la que tener una computadora que corriera tan rápido como 60 MHz era un sueño
      Las primeras computadoras que usé funcionaban aproximadamente a 1 MHz
      En máquinas lentas, la compilación tardará más, pero eso en sí no es un gran problema
      Si la computadora es estable y los scripts de compilación están bien, basta con dejarlos correr durante días o semanas
      En mi vida ejecuté muchas tareas que tardaban días o semanas
      Ver “compiling”: https://xkcd.com/303/
      El verdadero problema es la depuración
      Depurar en un sistema lento puede ser doloroso porque alarga los ciclos de iteración
      Históricamente, esto se resolvía dividiendo el proceso en etapas y permitiendo reiniciar desde varios puntos, para no tener que repetir todo el proceso completo cada vez
      Aquí funciona el mismo enfoque
      Además, también está la opción de depurar los scripts en un sistema más rápido pero menos confiable y, una vez confirmado que funcionan, ejecutarlos en el sistema lento