Programas de Linux.
Sin Linux debajo.
Rinux es un kernel escrito en Rust que ejecuta binarios Linux sin modificar dentro de dominios: cada uno con su memoria, su CPU, su raíz y sus fallos. Cuando algo cae dentro de un dominio, el resto de la máquina no se entera.
Haz clic en un dominio para provocarle un fallo.
Rinux es el sistema operativo, no algo que corre encima de uno.
Arranca directo en el servidor o en la VM de la nube, en lugar de Linux.
- No es Docker
- Docker necesita un Linux debajo y sus contenedores comparten ese kernel. Aquí no hay Linux: el kernel es Rinux. Toma imágenes de Docker tal cual y corre cada una en un dominio aislado por el propio kernel.
- No es una máquina virtual
- No hay un Linux invitado por cada carga. Un solo kernel aísla a todos los dominios.
- Sí es compatible con Linux
- Los programas (Debian, systemd, apt, sshd) no saben que no están sobre Linux, porque Rinux habla su mismo idioma de llamadas al sistema.
Esto ya corre.
Debian 13, desde una imagen OCI verificada capa por capa con SHA-256, arranca con systemd en un dominio de Rinux, en una VM de Google Cloud. Por SSH, apt instala paquetes y curl habla HTTPS. Todo lo que hacen por debajo lo resuelve Rinux.
- rinux> es la consola de rinuxd, el controlador del nodo. Crea, configura y arranca dominios.
- root@rinux-1 es el shell de Debian dentro del dominio, con su propia raíz y procesos. El nombre es el del nodo, que da el DHCP de la nube.
- La salida es la de una sesión real en x86_64, copiada del puerto serial de la VM y de SSH; se omiten líneas del arranque de systemd y de
apt. - La red del nodo parte cerrada y abre únicamente lo que se le concede a cada dominio: aquí, el puerto 22 y la salida. También corre
alpine:latestde Docker Hub, en x86_64 y aarch64.
Cada afirmación tiene una prueba que arranca la máquina.
Nada cuenta como hecho hasta que una prueba arranca Rinux en QEMU, en x86_64 y en aarch64, corre programas Linux reales dentro de un dominio y verifica el resultado desde adentro.
| Prueba | Checks | x86_64 | aarch64 |
|---|---|---|---|
| boot | 1 | pasa | pasa |
| mm | 8 | timer del host | pasa |
| elf-static | 1 | pasa | pasa |
| domains | 8 | pasa | pasa |
| vfs | 10 | pasa | pasa |
| proc | 17 | pasa | pasa |
| signals | 11 | pasa | pasa |
| tty | 11 | pasa | pasa |
| dynamic | 15 | pasa | pasa |
| alpine | 21 | pasa | pasa |
| threads | 15 | pasa | pasa |
| ipc | 12 | pasa | pasa |
| events | 14 | pasa | pasa |
| sockets | 12 | pasa | pasa |
| system | 13 | pasa | pasa |
| systemd | 11 | pasa | pasa |
| net | 3 | pasa | pasa |
| inet | 10 | pasa | pasa |
| gce | 4 | pasa | no aplica |
Todo el código inseguro vive en un solo lugar.
Rust no impide tocar el hardware; lo obliga a declararlo. En Rinux, todo lo que necesita unsafe (tablas de páginas, registros de dispositivos, DMA, cambio de contexto) está en un único crate con sus invariantes escritas. El resto del kernel tiene prohibido usarlo.
unsafe
27.272 líneas en el kernel, con #![forbid(unsafe_code)]
Dominios
Programas Linux sin modificar, con musl o glibc, y rinuxd, el controlador del nodo. Corren en modo usuario.
ring 3 en x86_64, EL0 en aarch64rinux-kernel
Memoria virtual, scheduler multiprocesador, dominios y capabilities, sistema de archivos, sockets, red TCP/IP, señales y la personalidad Linux que traduce cada syscall.
ring 0 / EL1, sin unsaferinux-frame
Paginación, interrupciones, contexto de CPU, MMIO y DMA, expuestos al kernel como tipos seguros.
el único crate con unsafeFirmware
UEFI arranca una sola imagen, RINUX.EFI. El kernel descubre la máquina por ACPI y verifica la firma Ed25519 del sobre de arranque antes de ejecutar nada.
x86_64 y aarch64 desde la misma fuenteMás fuerte que un contenedor, más liviano que una máquina virtual.
Un dominio no es un truco de espacios de nombres sobre un kernel compartido. Es un objeto del propio kernel, que posee sus recursos y responde por sus fallos.
- Capabilities con generación
- Cada permiso apunta a un objeto y a su generación. Cuando un dominio se reinicia, su generación avanza y todo permiso viejo deja de servir.
- Límites que se cumplen
- CPU y memoria con cuotas que aplican el scheduler y el asignador. Pasarse de memoria es un error del dominio, nunca del nodo.
- Perfil de syscalls
- Cada dominio tiene su lista de llamadas permitidas. Lo que no está se niega con el error que Linux daría y queda en la traza del kernel.
- Raíz propia en cada vida
- Capas OCI verificadas, procfs, sysfs, cgroups y dispositivos propios. Cada arranque del dominio parte de una raíz nueva.
- Política de fallo
- Detener, reiniciar o avisar a rinuxd. Un proceso que falla dentro de un dominio termina; el kernel y los demás dominios siguen.
- Una sola imagen
- Kernel, controlador y programas de arranque en un RINUX.EFI firmado por arquitectura. Se arranca, se verifica y toma la máquina.
La base de nuestro stack.
Cada pieza corre en su propio dominio, con su propia autoridad, en el mismo nodo.
- Hullorquesta cargas sobre dominios Rinux.
- Cóndorproxy inverso, con colas de red directas.
- OxideStorealmacenamiento de objetos y registro de imágenes.
- Melangerecibe la telemetría de cada nodo y cada dominio.
- Loaproxy de PostgreSQL delante de bases que corren en dominios.
- Lumoservicio nativo en su propio dominio.