Menos, por diseño
Single Purpose OS
Una máquina sin nada más que hacer.
Sin navegador. Sin escritorio. Sin shell. Sin inicios de sesión. Solo una tarea, construida únicamente con el código que necesita, sellada en compartimentos sobre el micronúcleo seL4 y escrita en Rust.
Ya funciona en QEMU y en la Raspberry Pi 5 · Código abierto, en GitHub
01 / El principio de una sola tarea
Cómo llegamos hasta aquí
Empezó en los lugares que no pueden permitirse un mal día.
No nos propusimos escribir un sistema operativo. Nos propusimos proteger unos pocos dispositivos muy importantes, y debajo de todos ellos encontrábamos siempre el mismo problema.
- El encargo
- Proteger los sistemas de los que depende un país: los controles que mantienen la electricidad en marcha y el agua limpia, las redes de las que depende un hospital, las pasarelas que sacan sus datos al exterior, los terminales de la sala de control y todos los dispositivos que los rodean, hasta la pantalla a la que se acerca un desconocido en un lugar público. Cada uno de ellos tenía una sola tarea. Cada uno ejecutaba un sistema operativo hecho para hacer miles.
- La trampa
- Un sistema de propósito general llega con todo lo que podría llegar a necesitar: un navegador, un escritorio, un shell, inicios de sesión, servicios en segundo plano. Si se bloquea para una sola aplicación, todo eso sigue ahí debajo, esperando a que alguien encuentre la forma de volver a ello. Cada línea de más es algo que parchear, y algo que atacar.
- El giro
- Así que nos hicimos la pregunta contraria: ¿y si el dispositivo contuviera solo su única tarea? Partimos de seL4, escribimos en Rust todo lo nuestro por encima, sellamos cada parte en un compartimento propio y dejamos fuera todo lo demás. Después pusimos las evidencias por escrito, para que nadie tenga que fiarse de nuestra palabra.
- La sorpresa
- Luego miramos a nuestro alrededor. La pasarela de la subestación, el terminal de la sala de control, el panel en el costado de una bomba, la caja entre dos redes, la pantalla en la pared de la estación: casi todos los dispositivos dedicados tienen una sola tarea. Lo que empezó como una armadura para las infraestructuras críticas resultó ser una forma mejor de construirlos todos. Lo llamamos Single Purpose OS.
Menos que atacar. Mucho menos que parchear. Nada más que hacer.
Qué queremos decir
El propósito, incorporado. Todo lo demás, fuera.
Un Single Purpose OS se construye para la única tarea de un dispositivo, en lugar de construirse para ejecutar cualquier cosa y luego restringirse a una sola. Tres rasgos lo definen.
Hecho para una sola tarea
La imagen del dispositivo contiene su aplicación, los controladores que esa aplicación usa y el núcleo. Ahí no hay nada que pueda necesitar otra tarea: ni navegador, ni escritorio, ni shell, ni gestor de paquetes, ni cuentas de usuario.
Sellado por dentro
Cada parte (la pantalla, la entrada, la red, la aplicación) se ejecuta en un compartimento propio y solo alcanza lo que se le ha concedido. Está diseñado para que un fallo en una parte se quede ahí.
Se deja comprobar
Viene con las evidencias de lo que contiene y de lo que puede hacer cada parte: cada concesión por escrito, cada componente en una lista y comprobaciones que cualquiera puede ejecutar.
No es un modo quiosco, que restringe un sistema de propósito general a una sola aplicación y deja todo lo demás en su sitio. Tampoco es un sistema operativo monousuario, que limita quién usa una máquina, no lo que contiene.
Lo que no está
Menos software. Por diseño.
La mayoría de los dispositivos dedicados ejecutan un sistema de propósito general con una aplicación encima y todo lo demás aún debajo. NoWayOS parte de la tarea, añade solo lo que necesita y deja fuera el resto. Esta es la diferencia.
| Un dispositivo bloqueado típico | Un dispositivo NoWayOS | |
|---|---|---|
| Navegador web y motor de JavaScript | Incluido | No incorporado |
| Escritorio y sistema de ventanas | Incluido | No incorporado |
| Shell y línea de comandos | Incluido | No incorporado |
| Gestor de paquetes | Incluido | No incorporado |
| Cuentas de usuario e inicios de sesión | Incluido | No incorporado |
| Servicios en segundo plano | Incluido | No incorporado |
| Ajustes para bloquearlo todo | Incluido | No incorporado |
| Núcleo | De propósito general: decenas de millones de líneas | seL4: unas 10 000 líneas |
| Controladores | Para el hardware que podría encontrarse | Solo para el hardware que usa |
| Su aplicación | Incluido | Incluido |
Screen Compiler
¿Le encanta React? A nosotros también.
¿Quiere interfaces ricas y modernas, creadas con el flujo de trabajo que ya conoce? Escriba sus pantallas en React. El Screen Compiler las convierte en componentes nativos de Rust que se ejecutan directamente en NoWayOS: sin navegador, sin JavaScript, sin página web que atacar.
- Conserve sus herramientas: componentes, props, tokens de diseño y el editor que ya usa.
- Piezas de verdad: layouts, texto, botones, campos de texto, casillas de verificación, grupos de opciones, tarjetas, avisos, barras de progreso e iconos.
- Exacto o nada. Convierte su subconjunto con exactitud y rechaza todo lo demás indicando el archivo, la línea y la columna. Nunca adivina.
- Comprobado al píxel. Cada pantalla convertida la dibuja NoWayOS y se compara con su imagen aprobada.
<Column gap={SPACE_SM} padding={SPACE_LG}>
<Text id="title">Welcome</Text>
<Text>Touch Start to begin.</Text>
<Button id="start" onPress={onStart}>
Start
</Button>
</Column>let n1 = b.text("Welcome")?; // welcome.tsx:17:9
let n2 = b.text("Touch Start to begin.")?;
let n5 = b.button("Start", actions::START)?;
let n0 = b.column(
ui::Layout::new()
.gap(super::tokens::SPACE_SM)
.padding(super::tokens::SPACE_LG),
&[n1, n2, n5],
)?;Versión abreviada de una de las pantallas de prueba del Screen Compiler y del Rust que genera.
Por qué importa
Una sola tarea. Y con eso basta.
Construya una máquina para una sola cosa y podrá construirla de una forma muy distinta. Esto es lo que gana con ello.
Más seguro
No hay manera de explotar lo que nunca se incorporó.
- Sin motor de navegador, sin sistema de ventanas, sin shell, sin gestor de paquetes, sin cuentas de usuario. Lo que no está en la imagen no se puede usar en su contra.
- La pantalla, la entrada, la red y su aplicación viven cada una en un compartimento sellado propio y solo alcanzan lo que se les ha concedido. Está construido para que un fallo en una parte se quede en esa parte.
- En el centro de todo está seL4, que la seL4 Foundation describe como “el núcleo de sistema operativo con el mayor nivel de garantía y el más rápido del mundo”.
- Rust de principio a fin. El código unsafe vive solo en un puñado de crates revisados, y la compilación hace cumplir esa lista.
Más eficiente
Nada ocioso. Nada que estorbe.
- Sin servicios en segundo plano y sin actualizador para software que nunca usa. Lo enciende y va directo a su única tarea.
- Cada byte se decide en tiempo de compilación: cada parte recibe una cantidad fija de memoria y nunca puede tomar más. La mayor parte del código del dispositivo no reserva memoria en absoluto, e incluso el cliente TLS tiene un presupuesto fijo: si alguna vez lo agota, se detiene limpiamente en lugar de crecer.
- Una interfaz nítida y nativa que solo vuelve a pintar lo que ha cambiado, a sus anchas en hardware de bajo coste como la Raspberry Pi 5.
Más fácil para desarrollar
Un lenguaje. Un contenedor. Primero, el emulador.
- Rust desde los controladores hasta la interfaz de usuario.
- Diseñe las pantallas en React. El Screen Compiler las convierte en Rust nativo en tiempo de compilación: una interfaz moderna sin motor de navegador ni JavaScript en el dispositivo. O escríbalas en Rust.
- Las cadenas de herramientas, el SDK de seL4 Microkit y QEMU vienen con sus versiones fijadas en un único contenedor de desarrollo. Su máquina solo necesita Podman y make, y Python para controlar una Raspberry Pi.
Más fácil de demostrar
Cada concesión, por escrito. Cada imagen, desglosada.
- Cada capacidad que concede un sistema figura en un archivo, y la compilación falla si ambos no coinciden.
- Cada imagen se entrega con una lista de materiales de software y un registro de su configuración de seL4.
- Demostraciones acotadas de que ningún decodificador de mensajes entra nunca en pánico, se desborda ni lee fuera de límites, además de fuzzing y comprobaciones de licencias y de avisos de seguridad: cada una, un comando que usted mismo puede ejecutar.
Cuando todo depende de él, dele una sola tarea.
Algunos dispositivos tienen un trabajo demasiado importante para compartirlo con distracciones: los controles de una red eléctrica, la pasarela de salida de una planta de agua, el terminal de una sala de control, la frontera entre dos redes. NoWayOS está diseñado en torno al papel que debe desempeñar cada dispositivo, con las evidencias que le ayudan a entender lo que contiene.
Pruebas, no adjetivos
Solo se ocupa de lo suyo. Puede comprobarlo.
Una afirmación de seguridad vale lo que valen las evidencias que la respaldan. NoWayOS pone las evidencias por escrito, y cada una de ellas sale de un comando que usted puede ejecutar.
Cada concesión, por escrito
El archivo de concesiones de cada sistema enumera cada prioridad, región de memoria, dispositivo, interrupción y canal que concede. La compilación falla si el sistema y la lista no coinciden.
Aislamiento puesto a prueba
Las pruebas de aislamiento intentan alcanzar lo que no se les ha dado, y seL4 debe impedirlo. Una variante con una concesión ampliada a propósito debe fallar, lo que demuestra que la prueba es capaz de fallar.
Cada imagen, desglosada
Una lista de materiales de software CycloneDX para cada imagen: el núcleo, el cargador, cada dominio de protección y los crates que contiene, cada uno con su hash.
Filtros fuera de alcance
Las comprobaciones que debe superar cada contribución viven en Defence Agent, un repositorio público propio, y un pull request que toca un filtro se señala al mantenedor.
En abierto
Cuatro proyectos. Una tarea cada uno.
Los cuatro son de código abierto y se desarrollan en abierto en la organización NoWayOS en GitHub. Puede clonarlos, compilarlos y revisar cada línea por su cuenta.
NoWayOS
El Single Purpose OS.
Patrones de dominios de protección sobre seL4 y Microkit, mensajes tipados, controladores, red y una interfaz de usuario nativa, junto con el contenedor de desarrollo y las comprobaciones con las que se construye cada repositorio de NoWayOS.
- Estado
- En desarrollo
- Licencia
- MIT OR Apache-2.0
Screen Compiler
Diseñe en React. Entregue Rust nativo. Sin navegador en el dispositivo.
Convierte pantallas de React, escritas en TSX dentro de un subconjunto declarado, en Rust para la interfaz de usuario de NoWayOS. Se ejecuta en tiempo de compilación, en su máquina o en la CI, y nunca llega al dispositivo.
- Estado
- En desarrollo: el subconjunto v0 y las primeras partes de v1
- Licencia
- MIT
Showcase
Aplicaciones seguras que puede ejecutar en una Raspberry Pi.
Un kit para pantallas de autoservicio seguras, una aplicación de referencia sobre la que construir y un lanzador de ejemplos con marcas ficticias en el que arranca la Raspberry Pi 5.
- Estado
- En una fase temprana, y no se puede desplegar
- Licencia
- MIT OR Apache-2.0
Defence Agent
Los filtros que debe superar cada contribución, fuera del alcance del pull request.
Cada filtro de seguridad que debe superar un cambio en los proyectos abiertos de NoWayOS, puesto por escrito junto con la amenaza a la que responde y quién puede cambiarlo, y el agente que los ejecuta. Un pull request nunca cambia ni aporta aquello que lo juzga.
- Estado
- Público: los filtros, por escrito; el agente y sus herramientas vienen después
- Licencia
- MIT OR Apache-2.0
Socios comerciales
Productos comerciales, construidos sobre NoWayOS.
Adappt.ai, patrocinador de NoWayOS, es su primer socio comercial. Está construyendo dos productos comerciales sobre NoWayOS, y ambos están en desarrollo.
¿Le interesa ser socio comercial? Escriba a partners@nowayos.com
- Remote Desktop
- Una vista reforzada. Un puesto seguro para un escritorio remoto de Windows, diseñado para sellar la conexión en un compartimento propio y mantener las credenciales fuera de su alcance.
- Data Diode
- No hay vuelta atrás. Una frontera unidireccional para sacar datos de una red protegida, diseñada en torno a un enlace que transporta luz en un solo sentido.
En qué punto está
Funciona hoy. Aún no está terminado.
NoWayOS está en desarrollo y aún no está listo para usarse en producción, y sus API cambiarán. Esto es lo que funciona hoy y lo que viene después.
- En QEMU
- Más de cincuenta sistemas arrancan y comprueban su propia salida, desde un primer dominio de protección hasta la pila de red obteniendo su dirección por DHCP, el estado de fallo seguro del supervisor y una interfaz de usuario en la que se puede hacer clic.
- En la Raspberry Pi 5
- La interfaz de usuario en una pantalla HDMI, un teclado y un ratón USB, los temporizadores, el watchdog y el reinicio del supervisor ya funcionan en la placa. Se está poniendo en marcha más parte de su hardware.
- Por llegar
- El arranque seguro, las actualizaciones firmadas aplicadas en el dispositivo y el hardware industrial (NXP i.MX8).
- Las demostraciones de seL4
- Todos los sistemas se ejecutan sobre seL4, pero ninguna imagen de NoWayOS usa todavía una configuración que cubran las demostraciones completadas de seL4. Cada imagen registra la que usa.
Siga el trabajo
Un solo propósito. Mucho por explorar.
Empiece por el diseño, examine las evidencias o construya su primer sistema con las guías para desarrolladores. Por cierto, este sitio sigue la misma regla: sin scripts, sin cookies, sin nada más que hacer.