Preguntas, respondidas sin rodeos.

El Single Purpose OS: un sistema operativo para dispositivos dedicados, como los sistemas de control de las redes eléctricas y de agua, los terminales de las salas de control y los diodos de datos unidireccionales, construido para la única tarea de cada dispositivo. Usted escribe la aplicación del dispositivo en Rust, y NoWayOS la construye, solo con los controladores que usa, sobre el micronúcleo seL4. La imagen contiene eso y nada más: ni motor de navegador, ni sistema de ventanas, ni shell, ni gestor de paquetes, ni cuentas de usuario.

Una máquina sin nada más que hacer.

Un sistema operativo construido para la única tarea de un dispositivo, en lugar de construirse para ejecutar cualquier cosa y luego restringirse a una sola. Tres rasgos hacen que un sistema operativo sea de propósito único:

• Hecho para una sola tarea. Su imagen contiene la aplicación, los controladores que esa aplicación usa y el núcleo, y nada más: ni navegador, ni escritorio, ni shell, ni gestor de paquetes, ni cuentas de usuario.
• Sellado por dentro. Cada parte se ejecuta en un compartimento propio y solo alcanza lo que se le ha concedido, así que un fallo en una parte está diseñado para quedarse 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.

Un Single Purpose OS 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, ni un sistema operativo monousuario, que limita quién usa una máquina y no lo que contiene. NoWayOS es un Single Purpose OS: una máquina sin nada más que hacer.

Porque no hay manera de explotar lo que nunca se incorporó. El nombre habla de lo que se deja fuera de un dispositivo, no promete que nunca pueda fallar nada de lo que se queda dentro. Lo que sí está incorporado puede tener errores; lo que afirmamos es que hay mucho menos, y que un error se queda en su compartimento.

Bloquear es seguro por configuración: el navegador, el escritorio y el shell siguen ahí detrás de los ajustes, siguen necesitando parches, y un solo error puede saltarse todos los ajustes a la vez. NoWayOS es seguro por construcción: esas partes nunca se incorporaron al dispositivo, y lo que queda se ejecuta en compartimentos sellados, de modo que un fallo en una parte está diseñado para quedarse en esa parte.

No. NoWayOS está en desarrollo, y todas sus API son provisionales y cambiarán. Más de cincuenta sistemas arrancan y se comprueban a sí mismos en QEMU, y la interfaz de usuario, el teclado y el ratón USB, los temporizadores, el watchdog y el supervisor funcionan en una Raspberry Pi 5. El arranque seguro, las actualizaciones firmadas aplicadas en el propio dispositivo y el hardware de producción todavía están por llegar.

Sí. NoWayOS, el Showcase y Defence Agent están bajo MIT OR Apache-2.0, a su elección, y el Screen Compiler es MIT. Los cuatro son públicos en la organización NoWayOS en GitHub: puede clonarlos, compilarlos y abrir una incidencia.

No, y tenemos cuidado de no darlo a entender. NoWayOS se ejecuta sobre seL4, que cuenta con demostraciones de corrección y seguridad comprobadas por máquina para configuraciones específicas en su hardware. NoWayOS usa la configuración de criticidad mixta de seL4, cuyas demostraciones para AArch64 están en curso, así que hoy ninguna imagen de NoWayOS está dentro de las demostraciones completadas de seL4. El código propio de NoWayOS no está cubierto en absoluto por las demostraciones de seL4; se apoya en Rust, en el aislamiento, en las pruebas y en demostraciones acotadas propias. Cada imagen registra su configuración exacta de seL4 (Seguridad).

No. La seguridad de NoWayOS viene de su diseño, no del secreto: de lo que se deja fuera y de los compartimentos que rodean lo que se queda dentro. Ser abierto permite que cualquiera compruebe lo que afirma, ejecute las evidencias e informe de lo que encuentre.

Está diseñado para que se quede en el compartimento donde está, lo que limita el daño mientras se prepara una corrección, y con mucho menos código hay muchas menos correcciones que hacer. Está previsto que las correcciones lleguen como actualizaciones firmadas que, si algo falla, vuelvan atrás de forma segura: eso está diseñado, pero todavía no construido. Para informar de una, escriba en privado, como describe el SECURITY.md de cada repositorio, y no en una incidencia pública.

Tal como está, no. NoWayOS ejecuta aplicaciones escritas para él, en Rust; no puede ejecutar programas de Linux o Windows, ni una aplicación web, porque nada de lo que necesitan viene incorporado. Las pantallas son la parte fácil: las pantallas de React escritas dentro del subconjunto admitido por el Screen Compiler se convierten a Rust nativo en tiempo de compilación. La lógica de la aplicación se reconstruye como dominios de protección de NoWayOS.

No. De eso se trata, precisamente. En un dispositivo NoWayOS no hay motor de navegador, ni WebView, ni JavaScript. Las pantallas son Rust nativo, dibujadas por la pequeña interfaz de usuario propia de NoWayOS, y aun así pueden diseñarse en React y convertirse en tiempo de compilación.

En la máquina AArch64 de QEMU, donde arranca primero cada sistema, y en la Raspberry Pi 5, la placa de referencia de bajo coste. La familia i.MX8 de NXP es el hardware de producción previsto, con una raíz de confianza en hardware; aún no está soportada. Para compilar NoWayOS necesita Podman (o Docker) y make: se desarrolla en Apple silicon, y los equipos x86-64 aún no se han probado.

Clone el repositorio nowayos, ejecute make container una vez y después make demo: la sesión guionizada de la demo interactiva se ejecuta en su máquina, con cada fotograma comprobado y sin necesidad de hardware. Después, make qemu-test SYSTEM=hello arranca seL4 en QEMU. Primeros pasos le guía paso a paso.