Rinux

Má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.

No es Docker

Docker necesita un Linux debajo y sus contenedores comparten ese kernel. Aquí no hay Linux: 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, y arranca en 129 ms.

Sí es compatible con Linux

Debian, systemd, apt y sshd no saben que no están sobre Linux, porque Rinux habla su mismo idioma de llamadas al sistema.

Esta página la sirve Rinux.

Un nodo en producción, sin Linux en ninguna capa

Esta página y otros sitios propios corren en un nodo Rinux en Google Cloud. En la misma máquina corren el plano de control de Mentat, que decide qué carga va dónde, y Cóndor, el proxy que termina TLS y obtiene los certificados de Let's Encrypt. Cada sitio vive en su propio dominio.

15a 21 ssin servicio al reiniciar la VM entera

463mspara traer esta página desde Santiago, TLS completo

12cargas y el plano de control en 2 CPUs y 8 GiB

Reset duro de la VM desde Google Cloud, con un sondeo cada medio segundo a cada dominio: seis volvieron a los 15 s y el más pesado, de 60 MB, a los 21 s. Los 463 ms son la mediana de 20 conexiones nuevas, con 148 ms de ida y vuelta hasta la nube.

VM mentat-1 n2-standard-2 8 GiBUEFI, virtio-scsi, virtio-net

rinux-loaderllave de producción, vuelve atrás si no arranca

ranura A kernel anterior

ranura B, gen 8 confirmada

Kernel Rinux (Rust)arranca en ~140 ms, personalidad Linux x86_64

dominios + pool de memoriarfs cifrado (vTPM)red: modo Marteegress off | node | metadata | on/dev/rinux-updatetcpbuf por dominio

rinuxddominio raíz: crea dominios, verifica firmas

start / stop de cargascontrol-oknode-okfirma minisign

dominio mentat

control, 2 GiB, update=on

mentat-server :4646 Raft líder

Condor :80 :443 ACME

registry Hull /var/lib/mentat

dominios mt-*

una carga por dominio, imágenes Hull firmadas

rinux-siteesta página :3041

baker-siteestático :3042

oxidestoreS3 :9000 Raft :8000

oxidestore-node2S3 :9001 Raft :8001

oxidestore-node3S3 :9002 Raft :8002

condor, hull, stilsitios estáticos

Raft de OxideStore entre dominios por la IP del nodo, sin Firecracker.

persistent-disk-0arranque, ranuras A/B

mentat-datarfs, 20 GB, estado

oxidestore x3rfs, 30 GB por nodo

Cargador con dos ranuras

Un kernel nuevo arranca una vez a prueba y, si el nodo no lo confirma, el cargador vuelve al anterior. Solo acepta imágenes firmadas.

Red cerrada por defecto

Cada dominio abre solo los puertos y la salida que se le conceden. Una carga con salida a internet no alcanza el servidor de metadatos.

Lo que encontró el tráfico real

Tres fallas, cada una con su prueba: un segmento TCP retenido, un lock que hacía girar un hilo y un plano de control lento al reponer cargas.

PostgreSQL, con cortes de energía de verdad.

Una base de datos es la prueba más dura para un kernel: cada transacción confirmada espera un fsync, y ese dato tiene que estar ahí después de cualquier apagón. PostgreSQL 17 de Debian corre sin modificar en un dominio de Rinux, y le cortamos la energía en plena carga.

200/ 200

transacciones confirmadas que sobreviven al corte con carga en curso

368

transacciones por segundo con 50 clientes en Google Cloud, sin una sola fallida

7,5ms

por transacción con un cliente: casi todo es el fsync del disco

El corte en la prueba

Con pgbench escribiendo, se confirman 200 transacciones marcadas y se apaga la VM sin aviso. Al volver, las 200 marcas están, los saldos cuadran y pg_amcheck no encuentra corrupción. En x86_64 y aarch64.

Colgado a propósito

Se congela el proceso principal: el puerto sigue abierto pero nadie responde. La prueba de vida del kernel lo detecta y reinicia el dominio; vuelve con las 200 marcas en menos de un minuto.

El corte en la nube

Reset duro de la VM desde la consola de Google Cloud: 200 de 200 marcas, saldos cuadrados sobre casi 80.000 transacciones y pg_amcheck limpio.

Lo que pidió PostgreSQL

Siete fallas del kernel, cada una con su prueba: memoria compartida System V, E/S vectorial, montajes apilados, red local por dominio y una lectura del disco que fallaba bajo carga.

Medido en la nube

n2-standard-2 con disco pd-balanced, pgbench escala 10: 133 tps con 1 cliente, unas 314 con 8 y 368 con 50.

Hecho para que nadie tenga que ir a arreglarlo.

Rinux apunta a nodos a los que no se puede ir: la red parte cerrada y todo pasa por el plano de control. Un nodo así tiene que volver solo de lo que lo deje sin servicio.

129ms

desde que entra el kernel hasta que está listo para trabajar

40s

hasta SSH en Debian, con PostgreSQL y el disco cifrado

18s

de una falla a SSH otra vez: el dominio de Debian se reinicia entero, solo

Disco que sobrevive al apagón

Copy-on-write y registro de intención: un corte deja el último estado confirmado, nunca una mezcla.

Cifrado por dominio

Cada volumen con su propia llave, sellada en el TPM. Borrar un dominio destruye su llave.

Actualizaciones con vuelta atrás

Si el kernel nuevo no arranca bien dos veces, o se cae tres veces en 10 minutos, el cargador vuelve solo al anterior.

Detector de bloqueo

Una CPU 20 segundos atrapada en el kernel se detecta, deja el motivo en el log y reinicia el nodo.

Prueba de vida por dominio

Cada 10 segundos el kernel verifica que el servicio acepte conexiones. Uno colgado se reinicia; uno detenido a propósito, no.

Watchdog en dos niveles

El de hardware reinicia la VM si el kernel se congela; cada dominio tiene su propio /dev/watchdog para systemd.

Un canal de control aparte

Un segundo SSH en un dominio independiente responde cuando Debian no. fail2ban bloquea en el propio kernel.

Escaneos que no cierran la puerta

Miles de conexiones a medias no dejan sin SSH al nodo: vencen, y la más vieja cede su lugar.

Memoria sin sorpresas

Sin sobrecompromiso ni un proceso que mate al azar: pedir de más da un error al pedir, siempre el mismo.

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.

245/ 375

llamadas al sistema de Linux 6.12 en x86_64, cada una con su estado escrito

214/ 318

en aarch64, con la tabla de números propia de esa arquitectura

pruebas de arranque completo, en las dos arquitecturas

Las pruebas, en el orden en que se fueron sumando
Prueba	Qué verifica	Checks	x86_64	aarch64
boot	UEFI, sobre firmado, rinuxd en modo usuario, apagado	1	pasa	pasa
mm	frames, heap, paginación, fallos, scheduler, timer	8	timer del host	pasa
elf-static	64 procesos estáticos en 4 CPUs	1	pasa	pasa
domains	aislamiento de fallos, capabilities, límites de memoria y CPU	8	pasa	pasa
vfs	tmpfs, devfs, procfs, syscalls de archivos	10	pasa	pasa
proc	fork, execve, wait4, pipes, posix_spawn, /proc/self/exe	17	pasa	pasa
signals	manejadores, máscaras, marcos de señal de Linux	11	pasa	pasa
tty	terminales, pseudoterminales, control de trabajos	11	pasa	pasa
dynamic	BusyBox dinámico de Alpine como init	15	pasa	pasa
alpine	imagen OCI desde un disco virtio, digest alterado rechazado	21	pasa	pasa
threads	pthread, futex, copy-on-write, páginas perezosas, TLB, mremap, stack que crece	15	pasa	pasa
ipc	mmap compartido, FIFOs, permisos, memoria compartida y semáforos System V, E/S vectorial, AIO nativo	18	pasa	pasa
events	epoll, eventfd, timerfd, signalfd, temporizadores POSIX	15	pasa	pasa
sockets	AF_UNIX, paso de descriptores, credenciales, netlink	12	pasa	pasa
system	montajes apilados, opciones de tmpfs, sysfs, cgroup2, inotify	15	pasa	pasa
systemd	Debian 13 con systemd como init, journal, login, nombre del nodo, SSH solo con llave, memoria según el nodo, hora de inicio de los procesos, watchdog, avisos de licencia	15	pasa	pasa
net	virtio-net, DHCP, ARP, ICMP, TCP	3	pasa	pasa
inet	sockets TCP y UDP, red cerrada por defecto, DNS, netlink, entrantes, red local propia de cada dominio, salida solo a metadatos	17	pasa	pasa
gce	imagen de Google Cloud: PCI sin MCFG, virtio legacy, login, SSH y actualización real	4	pasa	no aplica
blkw	escritura en disco por virtio-blk, virtio-scsi y NVMe, verificada desde el host	3	pasa	pasa
rfs	sistema de archivos propio en disco, revisado desde el host al apagar	9	pasa	pasa
crypt-persist	volúmenes cifrados que sobreviven reinicios y se destruyen con su llave	13	pasa	pasa
tpm	llaves selladas en el TPM, en tres arranques	11	pasa	pasa
loader	cargador propio con ranuras A/B	1	pasa	pasa
update	actualización en caliente, firma, kernel que no arranca y vuelta atrás sola	18	pasa	pasa
load	128 procesos escribiendo a la vez en un volumen cifrado	2	pasa	pasa
persist	Debian instalado en disco: lo cambiado sobrevive al reinicio	27	pasa	pasa
pg	PostgreSQL 17 con corte de energía en plena carga, y colgado a propósito	15	pasa	pasa
lockup	una CPU atrapada se detecta y el nodo se reinicia solo	2	pasa	pasa
unstable	un kernel que se cae tres veces vuelve solo al anterior	13	pasa	pasa
health	un servicio colgado se reinicia; uno sano o detenido no; watchdog de cada dominio	6	pasa	pasa
watchdog	el kernel entero congelado: el watchdog de hardware reinicia la máquina	1	pasa	pasa
syn	un escaneo de conexiones a medias no deja el puerto sin atender	1	pasa	pasa
keys	llaves SSH desde el servidor de metadatos, usuarios, cambios en caliente	12	pasa	pasa
hv	imagen para Proxmox y KVM: sin TPM lo explica; con TPM instala cifrado y vuelve a arrancar	3	pasa	pasa

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.

6.512 líneas en rinux-frame, con unsafe34.579 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 aarch64

rinux-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 unsafe

rinux-frame

Paginación, interrupciones, contexto de CPU, MMIO y DMA, expuestos al kernel como tipos seguros.

el único crate con unsafe

Firmware

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 fuente

Capabilities con generación

Cuando un dominio se reinicia, su generación avanza y todo permiso viejo deja de servir.

Límites que se cumplen

Cuotas de CPU y memoria. Pasarse es un error del dominio, nunca del nodo.

Perfil de syscalls

Lo que no está permitido se niega con el error que Linux daría y queda en la traza.

Red local propia

Cada dominio tiene su localhost; ninguno alcanza la red local de otro.

Dónde corre.

Rinux arranca como el sistema operativo de la máquina virtual. Todavía no está publicado: el código y las imágenes salen con la primera versión, bajo licencia MPL-2.0.

Google Cloud

Hoy en VMs n2-standard-2, con disco de arranque firmado y actualizaciones con vuelta atrás. C3, C4 y N4 necesitan el driver gVNIC, que viene.

Proxmox, QEMU/KVM, libvirt

Imagen lista: tres discos qcow2 y un TPM virtual, probada en x86_64 y aarch64.

AWS y Azure

En camino. AWS necesita el driver ENA; Azure, los dispositivos de Hyper-V.

Llaves desde la nube

La imagen no trae llaves ni contraseñas: las toma del servidor de metadatos.

Binarios de Linux, sin recompilar.Otro kernel debajo.