La bitácora de NoWayOS

Entra React, sale Rust

2026-11-13T00:00:00Z

Las interfaces modernas se diseñan en React. Por eso muchísimos dispositivos dedicados, desde paneles de control hasta máquinas de billetes, incluyen un motor de navegador entero, uno de los programas más grandes y más atacados que existen, para dibujar unos pocos botones y las palabras «Touch Start to begin».

Queríamos el flujo de diseño moderno sin el navegador. Así que construimos el Screen Compiler.

Escriba la pantalla en React

Sus diseñadores y desarrolladores de front-end conservan sus herramientas: componentes, props, tokens de diseño, su editor. Escriben la pantalla en TSX (esta está abreviada a partir de una de las pantallas de prueba del Screen Compiler):

<Column gap={SPACE_SM} padding={SPACE_LG}>
  <Text id="title">Welcome</Text>
  <Text>Touch Start to begin.</Text>
  <Spacer />
  <Button id="start" onPress={onStart}>Start</Button>
</Column>

Entregue Rust sin más

Durante la compilación, en su máquina o en CI, el Screen Compiler lo convierte en Rust para el runtime de interfaz de usuario de NoWayOS:

let n1 = b.text("Welcome")?; // welcome.tsx:17:9 <Text>
let n2 = b.text("Touch Start to begin.")?; // welcome.tsx:18:9 <Text>
let n4 = b.spacer(None)?; // welcome.tsx:20:9 <Spacer>
let n5 = b.button("Start", actions::START)?; // welcome.tsx:21:9 <Button>

Cada línea remite al TSX del que procede. El dispositivo recibe ese código y nada más: ni motor de JavaScript, ni navegador, ni página web que atacar. El propio Screen Compiler nunca se entrega con el dispositivo.

Exacto, o nada

Un conversor que adivina es un conversor del que no se puede fiar. El Screen Compiler convierte con exactitud su subconjunto declarado de TSX y rechaza todo lo demás indicando el archivo, la línea y la columna. Nunca aproxima. El Rust que escribe no tiene unsafe, ni unwrap, ni panic.

Después, el renderizador de NoWayOS dibuja cada pantalla convertida y la compara, píxel a píxel, con su imagen aprobada. Si se mueve un solo píxel, la compilación lo dice.

En qué punto está

El Screen Compiler está en desarrollo: su primer subconjunto está construido y el siguiente está en marcha. Es de código abierto bajo licencia MIT, en GitHub junto a NoWayOS. Si su equipo diseña en React y construye dispositivos que importan, nos gustaría saber de usted.

El respaldo que no era una copia

2026-11-13T00:00:00Z

Todo el mundo sabe que conviene tener un respaldo. Menos gente hace la incómoda pregunta siguiente: un respaldo ¿de qué, exactamente?

Cinco alarmas

El 20 de julio de 1969, el módulo lunar del Apolo 11 estaba a pocos minutos de la superficie de la Luna cuando su ordenador de guiado lanzó una alarma por la que la tripulación tuvo que preguntar al control de la misión. Luego otra. Cinco en total, en el último tramo del descenso.

El ordenador estaba sobrecargado. Lo que hizo a continuación es una de las grandes obras de ingeniería de esta historia: cada vez, se reinició, soltó el trabajo que podía esperar y retomó de inmediato el que no podía. El alunizaje siguió adelante.

Esa es la parte que todos cuentan. La parte que merece contarse después ocurrió al día siguiente.

El segundo sistema

El módulo lunar llevaba un segundo sistema de guiado, y no era una copia de repuesto del primero. Lo construyó otra empresa, sobre otro principio. El sistema principal mantenía la orientación con una plataforma que giraba libremente sobre cardanes. El segundo no tenía cardanes: sus sensores iban atornillados directamente a la nave, y calculaba dónde estaba arriba con aritmética.

Estaba allí para llevar a la tripulación de vuelta a la órbita si el sistema principal llegaba a detenerse. Durante el alunizaje no hizo falta.

Después, en el ascenso para acoplarse con el módulo de mando, una serie de maniobras llevó la plataforma del sistema principal a la única posición con la que una plataforma con cardanes no puede, y perdió su referencia de actitud. La tripulación pasó al segundo sistema para mantener estable la nave, y se acopló.

El segundo sistema no podría haber fallado del mismo modo. No tenía esa pieza.

Dos iguales

Ahora la otra historia. En 1996, el primer Ariane 5 despegó con dos unidades de referencia inercial que le decían hacia dónde apuntaba: una en funcionamiento y otra en reserva. Eran idénticas, hasta en el software.

A los treinta y siete segundos, un número dentro de ese software se hizo demasiado grande para el espacio que tenía reservado. La unidad de reserva se detuvo. La unidad en funcionamiento, que ejecutaba el mismo código en el mismo vuelo, se detuvo también. El informe de la comisión de investigación es público, y es tajante: no había nada a lo que cambiar, porque el respaldo ya había seguido el mismo camino.

Dos copias. Un fallo. No quedó nada.

Cómo lo llaman los ingenieros

Un fallo que se lleva por delante un sistema y su repuesto a la vez es un fallo de causa común. La defensa contra él es la redundancia diversa: un segundo sistema construido de forma lo bastante distinta como para que lo que detiene al primero no esté en el segundo.

El transbordador espacial volaba así. Cuatro de sus ordenadores de vuelo ejecutaban el software de una empresa; el quinto ejecutaba software escrito por separado por otra. Cuatro copias protegen de un ordenador que se avería. No protegen de un programa que está mal, porque los cuatro lo están ejecutando.

No sale gratis. El primer lanzamiento del transbordador se canceló cuando el quinto ordenador y los otros cuatro no lograron ponerse de acuerdo en la hora. Dos diseños dan más trabajo que uno, y hay que hacer que se encuentren.

Dónde entra NoWayOS

La mayoría de los dispositivos dedicados ejecutan hoy uno de un número muy pequeño de sistemas operativos de uso general. Sus respaldos también. Cuando aparece un defecto en un motor de navegador, un escritorio o un núcleo de decenas de millones de líneas, o cuando sale una actualización defectuosa, aparece en todos los lugares donde se ejecuta ese software, el mismo día.

Un dispositivo NoWayOS es distinto por dentro. Su núcleo es seL4, unas 10 000 líneas. Todo lo nuestro por encima de él está escrito en Rust. No tiene motor de navegador, ni escritorio, ni shell, de modo que un defecto en uno de ellos no está en él.

Eso significa que NoWayOS no tiene que sustituir lo que usted ya utiliza para ser útil. Puede estar a su lado: una segunda manera de hacer una tarea esencial, construida sobre otro principio.

Lo que no hace

La diversidad tiene límites, y preferimos que los conozca por nosotros.

Le da a un dispositivo NoWayOS fallos distintos, no ninguno. No hace nada por lo que dos sistemas comparten: la alimentación, la red, los servicios que hay detrás, o un error en lo que la tarea debía ser. Y algunas de las piezas de código abierto de NoWayOS se usan también en otro software, por lo que cada imagen enumera cada componente que contiene, para que usted pueda leer qué tiene en común con el sistema de al lado.

NoWayOS está en desarrollo, así que este es un papel para el que está diseñado, no uno que haya desempeñado ya. La página de seguridad dice en qué se apoya.

Los ingenieros del Apolo no llevaron un segundo sistema porque esperaran que el primero fallara. Lo llevaron porque no podían demostrar que no fallaría, y se aseguraron de que aquello que detuviera al primero no encontrara nada conocido en el segundo.

Atacamos nuestra propia compilación en cada cambio

2026-11-13T00:00:00Z

Esta es una pregunta incómoda para cualquier prueba de seguridad: ¿ha fallado alguna vez? Una prueba que nunca ha fallado puede estar pasando porque el sistema es sólido, o porque la prueba no ve nada en absoluto. Desde fuera, las dos cosas se ven exactamente igual.

Por eso NoWayOS no se limita a probar su seguridad. La ataca, en cada cambio, y comprueba que los ataques se detienen.

Alargar la mano hacia lo ajeno

Cada parte de un sistema NoWayOS se ejecuta en su propio compartimento sobre seL4, y solo tiene lo que se le concedió. Las pruebas de aislamiento envían sondas a propósito a través de esas fronteras. Una lee una dirección que nunca se le dio. Otra escribe en una página que solo puede leer. Otra, que tiene exactamente lo que tiene la interfaz de usuario, intenta escribir en la página de control de la pantalla, que la interfaz solo puede leer. Otra más, que tiene exactamente lo que tiene el cliente de red, intenta escribir en la memoria del controlador de red.

seL4 debe detenerlas todas, y una parte ajena al asunto debe seguir funcionando, intacta.

Una prueba hecha para fallar

Luego viene el giro. Junto a la prueba de aislamiento de la interfaz de usuario hay una variante con una concesión ampliada a propósito: al sustituto de la interfaz se le da la página privada de la pantalla. La prueba de esa variante debe fallar. Si alguna vez pasara, la prueba de aislamiento estaría ciega, y la compilación lo diría.

La misma idea recorre el resto de las comprobaciones. Cada decodificador de mensajes entre partes tiene demostraciones acotadas, del verificador de modelos Kani, de que nunca entra en pánico, nunca se desborda y nunca lee fuera de los límites. Después, las comprobaciones por mutación rompen los decodificadores deliberadamente, para mostrar que las demostraciones lo notan. Cada analizador de entradas externas se somete a fuzzing con datos hostiles.

Todo ello forma parte de make ci, el control que debe superar cada cambio. Las pruebas de aislamiento se ejecutan siempre; una demostración o una sesión de fuzzing se repite cada vez que cambia el código que cubre.

Controles fuera de alcance

Un control solo es tan fuerte como la mano que puede cambiarlo. Por eso las comprobaciones que debe superar cada contribución a NoWayOS están definidas en Defence Agent, un repositorio público propio. Una pull request que toca un control se señala al mantenedor.

Defence Agent se prueba a sí mismo del mismo modo: veinte pull requests trucadas, cada una con algo oculto que a un revisor se le podría escapar. Hay texto oculto de derecha a izquierda en un comentario, una letra cambiada por su doble cirílica, una dependencia obtenida directamente de un repositorio git, un workflow que ejecutaría código no fiable. Todas deben detectarse, mientras que tres cambios reales anteriores deben pasar.

Evidencias, no adjetivos

Nada de esto hace que un dispositivo sea “inhackeable”. Nada lo hace, y nunca lo diremos. Lo que le da son evidencias: un registro de lo que se intentó, de lo que se detuvo, y el comando que lo muestra. Lea las evidencias de una imagen real, o los propios controles.

Lo que una demostración puede prometer

2026-11-13T00:00:00Z

Por lo general se confía en el software porque se ha probado. Alguien pensó en las formas en que podía fallar, las ensayó y vio cómo respondía. Eso funciona bien, hasta que llega el caso en el que nadie pensó.

Una demostración empieza por el otro extremo. No ensaya casos. Muestra, con matemáticas, que una afirmación se cumple en todos.

Todos los casos, no solo los que probamos

Tomemos una promesa pequeña: este código nunca lee más allá del final de su búfer. Una prueba puede darle mil entradas, o mil millones, e informar de que ninguna lo hizo fallar. Una demostración dice algo de otra clase: no hay ninguna entrada que lo haga fallar. No se encontró ninguna, y no existe ninguna.

El precio es el rigor. Una demostración necesita un enunciado exacto de lo que el código debe hacer, su especificación, y un argumento que conecte cada línea del código con él. En el software real, ese argumento es demasiado largo para que una persona lo revise a simple vista. Así que lo comprueba un ordenador.

Comprobada por máquina

Eso significa «comprobada por máquina». La demostración se escribe completa, en un lenguaje que puede leer un programa llamado asistente de demostración, y el programa coteja cada paso con las reglas de la lógica. No se cansa en la página novecientos, y no se fía de la palabra de nadie.

Las demostraciones de seL4 se comprueban así, en un asistente de demostración llamado Isabelle/HOL. Son públicas, y cualquiera puede volver a ejecutarlas.

Qué dicen las demostraciones de seL4

seL4 es el núcleo sobre el que se ejecuta todo sistema NoWayOS: unas 10 000 líneas de código, y el único código con control total del dispositivo. Su tamaño es la clave. Un argumento sobre diez mil líneas se puede terminar. Uno sobre decenas de millones, todavía no.

La seL4 Foundation expone las demostraciones por capas:

El código hace lo que dice la especificación, y nada más. De ahí se sigue una lista de cosas que el núcleo no puede hacer: desbordar un búfer, seguir un puntero nulo, perder memoria, dividir por cero.
El programa que se ejecuta corresponde al código que se demostró. Entre ambos hay un compilador, así que otra demostración comprueba su salida.
El núcleo puede mantener separadas las partes de un sistema. Una parte no puede modificar los datos de otra, ni leerlos, ni quitarle los recursos que necesita, a menos que se le haya concedido ese derecho.
Un sistema puede arrancar en el estado para el que fue diseñado, con exactamente los permisos que enumera su descripción.

No todas las capas están terminadas para todos los procesadores y todas las configuraciones. Eso importa, y volveremos a ello.

Lo que una demostración da por sentado

Una demostración es exactamente tan amplia como su enunciado, y se apoya en sus supuestos. seL4 pone los suyos por escrito: que el hardware se comporta como dice su modelo, que unos pocos cientos de líneas del código de más bajo nivel son correctas, que el código que se ejecuta antes de que arranque el núcleo ha hecho su trabajo. La demostración de confidencialidad no cubre los tiempos de ejecución.

No dice nada sobre si la especificación pide lo correcto, ni sobre el software que está por encima del núcleo. Un núcleo demostrado aislará fielmente un programa que tenga un error. El error sigue ahí. Solo que no puede alcanzar nada más.

Eso no es una debilidad de las demostraciones. Es lo que las hace valiosas: dicen con precisión qué cubren, de modo que usted sabe con precisión qué queda.

Dónde está NoWayOS

Esta es la posición, sin rodeos. NoWayOS se ejecuta sobre seL4, pero ninguna imagen de NoWayOS está hoy dentro de las demostraciones completadas de seL4. NoWayOS usa la configuración de criticidad mixta de seL4, cuyas demostraciones para nuestros procesadores están en curso. Y las demostraciones de seL4 nunca cubrieron el código propio de NoWayOS. Por eso no decimos que NoWayOS esté “verificado formalmente”, y no lo diremos.

Cada imagen dice dónde está. Un archivo junto a ella enumera la configuración de su núcleo, opción por opción, frente a la que seL4 ha demostrado. Seguridad muestra uno real.

Demostraciones más pequeñas, las nuestras

El código de NoWayOS obtiene su garantía por otro camino: Rust, aislamiento, revisión, pruebas y demostraciones de un tipo más modesto.

Cada decodificador de los mensajes que pasan entre las partes de un sistema tiene demostraciones acotadas, hechas con un verificador de modelos llamado Kani. Una demostración acotada cubre toda entrada hasta un tamaño indicado, aquí el registro más largo que acepta un decodificador. Dentro de esa cota es una demostración de verdad: ninguna entrada hace que el decodificador entre en pánico, se desborde o lea fuera de los límites. Más allá de la cota no dice nada, y por eso la cota es la entrada más larga que existe.

Después rompemos los decodificadores a propósito, para asegurarnos de que las demostraciones lo notan. Una demostración que no puede fallar no es mejor que una prueba que no puede fallar.

Su tamaño real

Una demostración no hace que nada sea “inhackeable”. Hace que una afirmación sea cierta, en todos los casos, bajo supuestos que usted puede leer. Conozca la afirmación y los supuestos, y sabrá lo que tiene.

Por eso NoWayOS se construye sobre el núcleo que las tiene, y por eso le dice, imagen por imagen, hasta dónde llegan.

Por qué un dispositivo NoWayOS no tiene shell

2026-11-13T00:00:00Z

La mayoría de los ataques a un dispositivo dedicado no van contra la tarea que realiza. Van contra el resto del ordenador sobre el que se ejecuta: el shell que se dejó para mantenimiento, el servicio de acceso remoto que nadie apagó, el navegador que hay detrás de la aplicación, el escritorio que queda a un fallo de distancia.

Ese «resto del ordenador» está en todas partes. La pasarela que saca las lecturas de una planta de agua, el terminal de la sala de control de una red eléctrica, los dispositivos de los que depende un hospital, el panel en el costado de una máquina, la pantalla en el vestíbulo de una estación: muchos ejecutan un sistema operativo de uso general con una tarea encima, y todo lo demás sigue ahí debajo, desactivado mediante ajustes. El modo quiosco es la versión más sencilla. Cada intrusión es alguien que encuentra el ajuste que se pasó por alto.

Mejor dejarlo fuera

NoWayOS empieza por el otro extremo. Una imagen de NoWayOS contiene la aplicación del dispositivo, los controladores que usa esa aplicación y el micronúcleo seL4. Esa es toda la lista.

No hay shell en el que caer, porque nunca se incluyó ninguno. No hay inicio de sesión remoto cuya contraseña adivinar. No hay escritorio al que escapar. No hay motor de navegador esperando una página maliciosa. No se puede configurar mal un ajuste de un software que no está.

Todo eso se refiere al sistema operativo. La aplicación que va encima es otra cosa: puede hacer que sus usuarios inicien sesión, e iniciar sesión en otros sistemas, siempre que su tarea lo requiera. Lo que no tiene debajo es un sistema operativo en el que alguien pueda iniciar sesión.

A eso lo llamamos un Single Purpose OS: una máquina sin nada más que hacer.

Y lo que hay, está sellado

Dejar cosas fuera es la mitad. Cada parte que queda (la red, la pantalla, la entrada, la aplicación) se ejecuta en un compartimento propio, un dominio de protección en términos de seL4, y solo alcanza lo que se le concedió. El controlador de red mueve paquetes. El controlador de pantalla dibuja. La aplicación habla con cada uno mediante mensajes de tamaño fijo.

Cada concesión está escrita en un archivo, un hecho por línea, y la compilación falla si el sistema y el archivo no coinciden. Está construido para que un fallo en una parte se quede en esa parte.

«Pero ¿cómo se arregla sin un shell?»

Es lo primero que preguntan los ingenieros, y con razón. En el sistema operativo de un dispositivo NoWayOS no se inicia sesión: no tiene cuentas, así que no hay nadie como quien iniciarla. Se construye una imagen nueva y se sustituye la anterior. Hoy eso significa construirla y cargarla en la placa; las actualizaciones firmadas, comprobadas por el dispositivo y capaces de volver atrás de forma segura, están diseñadas y en camino.

A cambio se obtiene un dispositivo que arranca directamente en su única tarea, con mucho menos que parchear y mucho menos que atacar. Para los sistemas de los que depende un país, ese intercambio es justo lo que se busca.

Véalo usted mismo

Las evidencias de una imagen real de NoWayOS, su archivo de concesiones, su lista de materiales y su registro de configuración de seL4, están en nuestra página de seguridad. Sin registro, sin scripts. Solo los archivos.