NoWayOS
ES
GitHub
MenúCerrar

Plataforma

Construido a partir de la tarea.

Usted escribe su aplicación en Rust. NoWayOS la construye, solo con los controladores que usa, sobre el micronúcleo seL4. La imagen resultante contiene eso, y nada más.

De la aplicación a la imagen

Un dispositivo NoWayOS se construye, no se configura. Cuatro pasos llevan su código a un dispositivo que cumple su única tarea, y cada paso deja algo que usted puede comprobar.

  1. Escriba la aplicación

    En Rust, como uno o varios dominios de protección. Construya sus pantallas con el pequeño núcleo de interfaz declarativa de NoWayOS, o diséñelas en React y conviértalas en tiempo de compilación con el Screen Compiler.

  2. Describa el sistema

    Una descripción de sistema de Microkit declara cada dominio de protección, región de memoria, canal e interrupción. A su lado, un archivo de concesiones enumera todo lo que concede el sistema, y un archivo de salida esperada enumera lo que debe imprimir al ejecutarse.

    systems/hello.system   systems/hello.grants   systems/hello.expect
  3. Compílelo

    En el contenedor de desarrollo. La compilación coteja las concesiones con la descripción y después genera la imagen con su lista de materiales de software y un registro de su configuración de seL4.

    make image SYSTEM=hello
  4. Arránquelo, y deje que se compruebe a sí mismo

    Primero en QEMU: el sistema arranca sin pantalla y debe imprimir, en orden, cada línea que enumera su archivo de salida esperada, y nada de lo que ese archivo prohíbe. Después, en la Raspberry Pi 5, comprobado con el mismo archivo.

    make qemu-test SYSTEM=hello

Compartimentos sellados

Cada parte de un sistema NoWayOS (la pantalla, la entrada, la red, su aplicación) se ejecuta en un dominio de protección propio sobre el micronúcleo seL4. Un dominio de protección tiene su propia memoria y solo posee las capacidades que le concede su descripción de sistema: una capacidad funciona como una tarjeta de acceso para una sola puerta. seL4 las hace cumplir, así que cada parte solo alcanza lo que se le ha dado, y un error en una parte está diseñado para quedarse en esa parte.

  • Un supervisor recibe los fallos de las demás partes, detiene la parte que ha fallado y reinicia el sistema en limpio. Cuando los fallos se repiten, el dispositivo entra en un estado de fallo seguro, y solo un arranque en frío lo devuelve a la normalidad.
  • Un dominio de protección watchdog atiende al watchdog de hardware solo mientras todas las demás partes responden a su señal de vida.
  • Los roles limitan lo que se le puede dar a cada parte: la compilación rechaza una concesión que el rol de una parte nunca debe tener, como un dispositivo para una parte que solo debería dibujar.

Mensajes tipados, copiados antes de comprobarse

Los dominios de protección se comunican mediante registros de tamaño fijo y versionados, con una disposición explícita, que circulan por anillos de un solo productor sobre memoria compartida. Cada registro se copia fuera de la memoria compartida antes de comprobarse, así que el emisor no puede cambiarlo entre la comprobación y su uso.

Cada analizador de entrada externa pasa por fuzzing y está construido para no entrar nunca en pánico, y cada decodificador de mensajes tiene demostraciones acotadas, hechas con el verificador de modelos Kani.

Una pantalla nativa, y ningún navegador

La interfaz de usuario es un pequeño núcleo declarativo: disposición, foco y detección de pulsaciones en memoria acotada, dibujado con la biblioteca de Rust embedded-graphics y que solo vuelve a pintar lo que ha cambiado. El texto sale de atlas de glifos dibujados de antemano, en tiempo de compilación, así que el dispositivo nunca analiza un archivo de fuente. Las aplicaciones ven eventos de teclado, de puntero y táctiles, nunca USB ni ningún otro protocolo de dispositivo.

Los diseñadores pueden seguir trabajando en React. El Screen Compiler convierte en Rust, en tiempo de compilación, las pantallas escritas dentro de su subconjunto admitido, y rechaza todo lo que queda fuera de ese subconjunto en lugar de aproximarlo.

Qué contiene

Área Lo que le da NoWayOS
Entorno de ejecución Patrones de dominios de protección sobre Microkit y rust-sel4; un supervisor que detiene una parte que ha fallado y reinicia el sistema en limpio, con un estado de fallo seguro tras fallos repetidos; un watchdog
Mensajes Registros tipados con una disposición explícita en el formato de transmisión, y anillos de un solo productor sobre memoria compartida
Controladores Pantalla (el ramfb de QEMU, el framebuffer de la Raspberry Pi 5); entrada (virtio, teclados, ratones y tabletas USB); red (virtio-net, el Ethernet de la Pi 5); host USB (xHCI); UART; temporizadores; el ventilador de la Pi 5
Red Una pila IP sobre smoltcp con DHCP y TCP, que solo se conecta a los destinos que permite el sistema; un cliente TLS 1.3 sobre rustls y RustCrypto
Tiempo y confianza Tiempo monótono y hora de reloj como tipos que nunca se mezclan; verificación de firmas ECDSA P-256; los registros de las actualizaciones firmadas; semillas de una fuente aleatoria de hardware con pruebas de salud
Interfaz de usuario Un núcleo de interfaz declarativa acotado, con disposición, foco y detección de pulsaciones; un renderizador sobre embedded-graphics; atlas de glifos e iconos dibujados de antemano
Herramientas El contenedor de desarrollo; fragmentos de make con los que se construyen los repositorios de producto; las comprobaciones de concesiones, de unsafe, de licencias y de secretos; herramientas de SBOM y de evidencias de versión; ejecutores para QEMU y Raspberry Pi

Hardware

Dónde Su papel
QEMU (AArch64) Cada sistema arranca aquí primero, dentro del contenedor de desarrollo, y comprueba su propia salida
Raspberry Pi 5 La placa de referencia de bajo coste que cualquiera puede comprar. La interfaz de usuario, la entrada USB, los temporizadores y el watchdog ya funcionan en ella
NXP i.MX8 El hardware de producción previsto, con una raíz de confianza en hardware. Aún no está soportado

NoWayOS se desarrolla en máquinas con Apple silicon (arm64). En x86-64 los paquetes de la imagen de desarrollo también están fijados y revisados, pero la imagen todavía no se ha compilado ni probado allí de principio a fin.

Construido sobre

NoWayOS se apoya en el trabajo de otros, y lo dice: seL4, Microkit, rust-sel4, las colas de red del seL4 Device Driver Framework, smoltcp, rustls, RustCrypto y embedded-graphics.