Kernel soberano, escrito en Rust
Userspace Linux. Sin Linux debajo.
Rinux es un kernel y sistema operativo propio que ejecuta binarios Linux sin modificar dentro de dominios nativos: fronteras de aislamiento, recursos, ciclo de vida y fallo más fuertes que un contenedor. Es la base de ejecución de nuestro stack, del primer arranque al último paquete de red.
Lo que Rinux es, y lo que no negocia.
Linux es una personalidad que Rinux expone, no el sistema que corre debajo. Cada decisión del kernel sale de seis principios.
Linux sin Linux debajo
Binarios ELF de Linux, estáticos y dinámicos, con musl o glibc, corren sin recompilar. La compatibilidad es observable y documentada, syscall por syscall.
El dominio como frontera
La unidad de aislamiento, ownership, recursos y fallo es un objeto nativo del kernel. Un fallo dentro de un dominio nunca alcanza al kernel ni a otro dominio.
Seguro por defecto
Capabilities explícitas, revocables y con generación. Toda syscall fuera del perfil del dominio se deniega. Ante la duda, se niega.
Una sola imagen
Kernel, controlador y catálogo de arranque en un único RINUX.EFI firmado. Se arranca, se verifica y se toma la máquina.
Dos arquitecturas
x86_64 y aarch64 desde el primer día. Nada existe en una si no existe en la otra.
Dependencias mínimas
Scheduler, memoria virtual, VFS, capabilities, IPC y red son propios. Cada dependencia externa se justifica por escrito o no entra.
Un framekernel: el unsafe vive en un solo lugar.
Un único crate, rinux-frame, concentra todo el código unsafe: paginación, MMIO, DMA, contexto de CPU, interrupciones y asignación de frames, cada bloque con su invariante escrita. El resto del kernel declara forbid(unsafe_code) y se construye sobre abstracciones seguras.
El kernel portable no toca hardware: pide a rinux-frame abstracciones seguras como UserSpace, VmMapping, DmaRegion, IoMem, IrqLine y CpuLocal.
Más fuerte que un contenedor. Más liviano que una VM.
Un dominio es un objeto nativo del kernel. No es un namespace emulado ni un cgroup con buena voluntad: posee sus recursos, responde por sus fallos y vive bajo una política que el kernel hace cumplir.
- Capabilities con generaciónCada autoridad es un par objeto y generación. Al morir o reiniciar un dominio su generación avanza y toda capability vieja queda inválida al instante.
- Límites durosCPU y memoria con cuotas que el scheduler y el asignador aplican de verdad, no por mejor esfuerzo. Exceder la memoria es un error del dominio, nunca del nodo.
- Perfil de syscallsLista permitida por dominio. Lo que no está, se deniega con el errno documentado y queda en la traza del kernel.
- Raíz propiaCapas OCI de solo lectura, overlay escribible y tmpfs, procfs y devfs seleccionados. Cada vida del dominio arranca con una raíz nueva.
- Red y dispositivosEndpoints de red con direcciones propias y grants de dispositivo acotados. Dos dominios se hablan solo si se les concede.
- Política de falloDetener, reiniciar o escalar a rinuxd. Un proceso que falla dentro de un dominio termina; el kernel y los demás dominios no se enteran.
Dos formas de hablar con el kernel.
Una para todo el software Linux que ya existe. Otra para el software que escribimos nosotros, sin pagar el peaje de POSIX.
El ecosistema entero, tal cual
Formato ELF, tablas de syscalls de Linux 6.12 para cada arquitectura, señales, terminales y pseudoterminales, relojes, sockets y los sistemas de archivos que los programas esperan. Alpine con BusyBox, Debian y Rocky con systemd hasta multi-user.target, PostgreSQL bajo carga. El estado de cada número de syscall está escrito en un ledger: completa, parcial, denegada por política o no implementada.
El camino directo para nuestro stack
Servicios compilados contra librinux: capabilities en primera persona, IPC nativo y colas de red directas, sin emulación POSIX de por medio. Es como corren Cóndor, Loa, Lumo y OxideStore cuando cada microsegundo cuenta, con la misma frontera de dominio que cualquier carga Linux.
De firmware a servicio, con una cadena de confianza.
Rinux está pensado para servidores: sin pantalla, sin intervención, descubriendo la máquina por tablas y no por direcciones fijas.
rinuxd
Corre en ring 3 como un proceso más. Define dominios, gestiona recursos, adjuntos y autoarranque, mantiene el caché de imágenes y habla con el kernel por un ioctl versionado y verificado. Consola rinux> por serial y API remota con autenticación mutua.
OCI como transporte
OCI se usa para mover imágenes, no como runtime. Rinux descarga, verifica cada digest SHA-256 y ensambla las capas en la raíz del dominio, con caché persistente direccionado por contenido. OxideStore sirve como registry y almacén de capas.
rfs
Formato propio, simple y con journal, para el volumen del host. Un apagado abrupto en plena escritura deja los metadatos intactos. Overlays persistentes por dominio cuando se piden.
rinux-net
Pila TCP/IP propia: IPv4 e IPv6, TCP con control de congestión, UDP, ICMP, ARP y NDP, cliente DHCP y DNS. Enlaces virtuales por dominio con direcciones propias.
Drivers aislados
Solo virtio moderno, con MSI-X y GICv3 ITS. El driver de red y la pila corren en un dominio de servicio en ring 3, con autoridad acotada sobre MMIO, DMA y colas. Todo DMA queda confinado por el IOMMU. Si el dominio de red cae, el kernel sigue y rinuxd lo levanta.
Trazas y OTLP
Ciclo de vida de dominios, fallos, denegaciones y presión de memoria pasan por un ring buffer de trazas del kernel. rinuxd exporta métricas, logs y trazas por OTLP hacia Melange, y /proc/rinux expone contadores por dominio.
- Perfil de servidorHeadless: serial y API remota. ACPI como fuente de verdad en ambas arquitecturas, SBSA/SBBR en aarch64; consola por SPCR, PCIe por MCFG, CPUs por MADT.
- EscalaMuchos núcleos con x2APIC y GICv3, NUMA en el diseño del asignador y del scheduler, mapas de memoria grandes.
- Sin intervenciónAutoarranque de dominios, reinicio por política y fallos que nunca tumban el nodo.
La base de todo lo nuestro.
En un solo nodo Rinux, cada pieza del stack vive en su propio dominio, con su propia autoridad, y el tráfico fluye de extremo a extremo sin capas prestadas.
Hull
Orquestación de cargas sobre dominios Rinux.
Cóndor
Proxy inverso en la personalidad native, con colas de red directas.
OxideStore
Almacenamiento de objetos, registry OCI y almacén de capas.
Melange
Destino de la telemetría OTLP de cada nodo y cada dominio.
Loa
Proxy de PostgreSQL delante de bases que corren en dominios.
Lumo
Servicio del stack nativo, en su propio dominio.
Rinux
Un kernel que nos pertenece, para el software que corremos.
Rust de punta a punta, unsafe confinado y auditado, dos arquitecturas, una imagen firmada y dominios que el kernel defiende. Todo el userspace Linux, y un camino directo para lo nuestro.