La advertencia previa sigue igual: el proyecto es pre-alfa, la primera publicación es solo para VPS con KVM, y las cifras miden código, pruebas y experimentos concretos, no madurez en producción.

Cómo se vio en el tiempo

Desde el texto anterior (31.10. a las 23:00) hasta hoy (1.11. a las 20:41) hay 59 commits nuevos en el repositorio, 178 en total. Todos se hicieron en un solo día natural, así que vale la misma advertencia de antes: el proyecto se construye con Claude Code (los commits llevan Co-Authored-By: Claude), el plan, el código, las pruebas y los ADR se escriben en bucles cortos y cerrados, y las cifras de abajo hablan de la cantidad de código y de comprobaciones, no de cuánto trabajo humano hay en ellas.

Las cifras se calcularon con el mismo método que en el texto anterior: todos los archivos .rs fuera de vendor/ y fuzz/, las funciones #[test] y los títulos ## ADR- en docs/DECISIONS.md.

Se trabajó en paralelo en varias ramas, así que el orden de los commits no es estrictamente el orden del trabajo. Los ADR están numerados hasta el 232, pero la numeración tiene huecos (una parte se renombró al fusionar ramas); contamos los títulos, no el número más alto. Versiones: v0.2.0 (1.11., 18:45 UTC) y v0.2.1 (1.11., 20:22 UTC), ambas marcadas como pre-release.

H6: SQLite en modo usuario

Qué habíamos planeado. SQLite son 254 268 líneas de C que analizan la base de datos, el WAL y el diario desde el disco, y el disco puede estar fabricado o modificado. Hasta entonces funcionaba dentro del núcleo, con los privilegios del núcleo. Qué construimos (ADR-210 a ADR-212): SQLite, sus partes de libc y el heap se trasladaron a un programa aparte, dbworker, que se ejecuta en EL0 (aarch64) o en ring 3 (x86_64), en su propio espacio de direcciones. El núcleo ya no enlaza SQLite. El worker habla con el núcleo a través de una ventana de memoria compartida y doce llamadas al sistema, y cada longitud y cada desplazamiento devueltos se comprueban antes de usarse. Un fallo en el worker (acceso no permitido, instrucción indefinida, superado el presupuesto de tiempo de 30 s) termina la llamada, el worker se reinicia y la base de datos se abre desde el WAL como en el arranque; tras 5 reinicios en un minuto el almacenamiento se declara defectuoso y no se reinicia indefinidamente.

El coste, medido en aarch64 bajo HVF, la misma VM, núcleo con SQLite integrado frente a núcleo con worker, seis ejecuciones alternas de cada uno:

Las escrituras en disco (1572) y los flushes (319) son idénticos, como debe ser. Lo que no está aislado es esto: el núcleo sigue confiando en lo que devuelve el worker, tras comprobar su forma. Un worker comprometido puede mentir (por ejemplo, devolver una lista vacía de certificados revocados y así "desrevocarlos"), pero no puede leer la memoria del núcleo, ni las claves TLS, ni las claves de los tickets. No hay KPTI, así que las fugas de tipo Spectre/Meltdown no están impedidas y no afirmamos nada sobre ellas; la clave PAC la comparten EL0 y EL1. En x86_64 no medimos el coste del cambio en KVM (bajo TCG la cifra no tendría sentido), y el fuzzing del propio worker y del protocolo no está terminado. El conjunto de pruebas de almacenamiento (79 escenarios, cada uno ejecuta SQLite en el worker) pasa en aarch64 HVF y en x86_64 TCG, y en aarch64 TCG pasan 76 (uno se omite porque TCG no tiene MSI-X).

H7 está cerrado, pero no como anunciamos. El límite inferior del tiempo (ADR-050) y SNTP con consenso (T1) cubren el alcance de H7; NTS (RFC 8915) queda fuera del alcance y está anotado como riesgo restante, no como algo que funcione. No consideramos que la seguridad del tiempo esté "resuelta", sino que su parte demostrable está hecha.

Nueva opción de red. Contabo no da DHCP a una ISO personalizada, así que hasta entonces el VPS necesitaba una imagen distinta de la de la VM de laboratorio. Ahora network.mode = "auto" (ADR-214) pregunta primero al DHCP y, si no hay concesión en el plazo configurado (dhcp_timeout_s, por defecto 15 s) o la pierde, aplica la dirección estática por defecto. Probado a mano en QEMU (con DHCP usa la concesión, sin red vuelve a la dirección estática a los 5 s); todavía no hay un escenario de smoke para esto.

X11: comparación con Mosquitto en el mismo VPS

El mismo tipo de máquina que en el texto anterior (Contabo, 4 vCPU AMD EPYC, 8 GiB), carga desde un host Linux a 15 ms, TLS 1.3 mutuo con los mismos certificados en ambos lados, Mosquitto 2.0.21 en Debian 13 sin persistencia. El método y las decisiones están en el ADR-213, los datos en bruto en docs/perf-results/. Mediana de tres ejecuciones.

Qué significa y qué no. Los handshakes son límites inferiores para ambos servidores: el generador de carga es una VM compartida con 60 a 70 % de tiempo de procesador robado y con 128 hilos estaba cerca de su propio límite, mientras que los núcleos de trabajo de urMQTT estaban ocupados solo un 12 a 13 %. La proporción con 128 clientes (unas 2,2 veces) es la más significativa; con 32 y 64 mide sobre todo la espera de los clientes. Las cifras de memoria no cuentan lo mismo (heap del núcleo frente a RSS del proceso), así que "unas 50 veces menos" es un orden de magnitud, no una proporción precisa. La latencia de 14 ms es una vuelta de red (unos 15 ms), es decir, "sin tiempo medible del broker"; las colas (p99 de unos 100 a 200 ms) están dominadas en ambos brokers por los hosts compartidos. No afirmamos diferencias inferiores a un 20 % aproximadamente.

Lo que no salió a nuestro favor y quedó en las tablas: un solo flujo TCP a través de urMQTT transportó de 2 a 8 veces menos que a través de Mosquitto, con variaciones de cero a 7,7 mil mensajes por segundo entre ejecuciones, y el watchdog de 20 ms del manejador cortaba conexiones vivas cuando el hipervisor detenía una vCPU (en la configuración de producción action = "drop", de 6 a 8 conexiones por ejecución con inundación QoS 0). Ambas cosas se describen en la sección siguiente porque tenían causas en nuestro código.

Por qué el flujo único era lento: causas, no excusas

Lo más fácil habría sido decir "VPS compartido". No lo dijimos; con el mismo VPS y el mismo método buscamos las causas. Se encontraron cinco, cuatro en el camino de datos y una en el watchdog (ADR-221 a ADR-224):

Las detenciones son reales: en este VPS los núcleos 0 a 2 tuvieron una mediana de 36 a 80 ticks retrasados por cada 5 segundos, y la peor detención en la ventana tuvo una mediana de unos 70 ms y llegó a 0,9 s (núcleo 3, base de datos y diario: hasta 1,55 s), mientras que el host no informa de tiempo robado (host steal 0 us). Por eso el watchdog necesitaba otro reloj, no un presupuesto mayor.

Watchdog: 148 conexiones cortadas en 30 ejecuciones con carga antes, 0 en 24 ejecuciones después; en un aparato local que retrasa y pierde tramas, con una pérdida del 0,1 % un flujo de 64 B con 14,3k mensajes/s (núcleo de X11) ahora tiene 41,0k, y con 0,5 % pasa de 5,0k a 17,7k.

Lo que esto no dice. urMQTT sigue sin ser más rápido que Mosquitto en un solo flujo: con 64 B publica alrededor del 80 % de su velocidad y entrega alrededor del 40 %, porque descarta QoS 0 cuando el flujo del suscriptor es más lento que el del publicador (Mosquitto, sin límite, lo pone en cola). Con 1 KiB en la inundación de 16 pares Mosquitto va por delante en un 15 % aproximadamente, lo cual está dentro del ruido. El generador volvió a ser una VM compartida con 58 a 77 % de tiempo robado. La segunda ronda (bloqueo del heap fuera del camino de datos, SACK en el lado de envío y otras cosas) está en la rama no integrada perf-single-flow-wip; sus cifras todavía no son afirmaciones y no las damos aquí.

Una promesa que no hicimos, pero cumplimos: la configuración es un dato

Hasta ahora cada configuración era una compilación nueva: las claves y los límites estaban integrados en la imagen. C1 lo invierte (ADR-215 a ADR-219): el núcleo se compila una vez y la configuración es un dato.

• Blob urmqtt-cfg (C1a): un registro versionado y canónico (campos por etiquetas crecientes, huella SHA-256, firma Ed25519 separada opcional), 70 campos con valores por defecto y límites, y un decodificador que rechaza todo lo que sea incorrecto.
• El núcleo lo lee como módulo de Limine (C1b), antes que cualquier otra cosa, en aarch64 y x86_64. Hay un núcleo publicado para cada ENV excepto dev (los ELF de aarch64 para release, prod y bench tienen el mismo SHA-256; comprobado solo en aarch64). El núcleo publicado rechaza una configuración de desarrollo y, sin configuración, escribe "refusing to serve" y no sirve nada.
• El disco instalado lleva la configuración y la actualización la conserva (C1c).
• urmqtt-config y la plantilla de ISO (C1d): pack, show, verify, y pack --iso sustituye las dos copias del espacio de configuración y los 24 resúmenes de módulos en una ISO ya hecha. El resultado es idéntico byte a byte a la ISO que construye mkiso.sh --config. La plantilla de la versión v0.2.0 tiene 63 111 168 bytes.
• Declaración de confianza (ADR-219): una imagen configurada escribe al arrancar la huella de la configuración (config: fingerprint ...), y la firma es opcional y está desactivada por defecto. Una ISO modificada no tiene el resumen oficial; la huella es la forma de ver qué contiene.

El constructor en aldo.tech

Lo mismo que hace urmqtt-config pack --iso lo hace la página web, con el mismo código: la biblioteca de la herramienta compilada a WebAssembly (1,06 MB, sin importaciones y sin bloques unsafe). La página está en aldo.tech/es/productos/urmqtt-builder/ y existe en los 15 idiomas del sitio (por ejemplo hr).

• Nada sale del navegador. Los certificados, las claves privadas y la ISO terminada se quedan en el ordenador; la página solo descarga los archivos de la versión desde este sitio, sin seguimiento ni scripts de terceros. En la prueba en vivo ninguna petición llevó material de claves.
• Espejo de versiones (ADR-227): hora a hora (temporizador de systemd, de baja prioridad) copia las versiones desde GitHub, verifica cada una antes de publicarla, y la página comprueba en el navegador la firma de SHA256SUMS con una clave integrada en la página, y solo entonces escribe la configuración en la plantilla. Si la comprobación falla, se bloquea la descarga.
• Sencillo por defecto, avanzado si hace falta (ADR-232): la primera pantalla son tres pasos (dónde funciona, sus certificados, nombre de la imagen). Un único campo para arrastrar archivos clasifica certificado, clave y CA por su contenido. La vista avanzada abre cada uno de los 70 campos, la búsqueda, la importación y la exportación de TOML; ambas vistas editan el mismo estado. La plantilla (63 MB) se descarga mientras el usuario rellena el formulario. En la prueba en vivo, con un espejo de prueba y una clave de prueba, la construcción de la ISO en el navegador tardó de 5 a 18 s.

El emulador, opcional. Junto a "Descargar ISO" está "Probar en el emulador": QEMU compilado a WebAssembly ejecuta la imagen recién construida en una pestaña del navegador. Nada de él se descarga antes del clic (unos 3 MB la primera vez). El emulador es solo BIOS, sin red (para que el tráfico del usuario no pase por algún intermediario y rompa el "nada sale del navegador"), necesita unos 1,5 GB de memoria y un navegador de escritorio (probado Chrome; Firefox y Safari no). En él urMQTT llega a URMQTT READY en unos 8 s (con la cuenta atrás omitida) y escribe la misma huella de configuración que la página, lo que demuestra que se arrancó justo esa configuración. El arranque es unas 2 veces más lento que en el QEMU nativo en el mismo Mac (0,82 s frente a 1,9 s), y la criptografía unas 58 veces más lenta porque las instrucciones de hardware están emuladas. Por eso del emulador no sacamos ninguna afirmación de velocidad, y la página lo dice antes de iniciarlo. En la construcción hubo que parchear cuatro bytes en el .wasm por un fallo en la traducción de la instrucción POPCNT en el emulador original (todavía no lo hemos notificado); el emulador en sí está bajo GPL, con oferta del código fuente.

MQTT en claro, solo para redes en las que confía

MQTT en claro (TCP 1883, sin TLS) es muy común en IoT: es el valor por defecto en Mosquitto, en la mayoría de los firmwares de Arduino y ESP, en Tasmota, Zigbee2MQTT y Home Assistant, y se usa también dentro de redes industriales segmentadas, detrás de VPN y en LAN privadas, e incluso en dispositivos sin reloj (los certificados exigen una fecha), sin suficiente flash o procesador para TLS. Sobre una red no fiable no es aceptable: quien está en el camino lee y modifica el tráfico. Por eso P1 (ADR-229 a ADR-231) es una opción explícita y limitada, desactivada por defecto, y el puerto TLS se mantiene; con esto no se desactiva TLS, el puerto en claro viene además.

• La lista de redes permitidas es obligatoria (allow_from, CIDR) y se comprueba en el SYN: fuera de la lista no hay SYN-ACK ni estado. Todo internet (0.0.0.0/0) exige una opción explícita aparte.
• Tres modos de inicio de sesión: contraseña (por defecto cuando está activado; PBKDF2-HMAC-SHA-256, sal, 10 000 iteraciones, comparación en tiempo constante, bloqueo por dirección), anónimo (una identidad configurada con su propia ACL) y por dirección (ip). El constructor calcula el hash de la contraseña en el navegador y en memoria solo conserva el resumen.
• Menos privilegios que mTLS: un cliente en claro nunca tiene privilegios de servicio, de operador ni de gestión, no tiene $SYS ni consola, tiene sus propias sesiones ($plain/<identidad>/<id del cliente>, solo limpias), y sus propios límites y el registro de permitidos lo siguen obligando.
• Lo que se pierde está en SECURITY.md: confidencialidad, integridad, autenticidad del broker y repetición de un inicio de sesión capturado. Esto no se puede arreglar con la configuración; así es cuando no hay TLS.

Medido en un portátil (Apple silicon, HVF, red de usuario de QEMU), 16 pares, 64 B, tres ejecuciones de 10 s: con 8000 mensajes por segundo, el camino TLS y el camino en claro entregan todos los mensajes con la misma latencia (p50 0,17 ms frente a 0,13 a 0,18 ms); conexiones nuevas por segundo: TLS unas 2600 a 2750, en claro anónimo unas 4900 a 7800, y el inicio de sesión con contraseña es la parte cara: un PBKDF2 cuesta unos 2,5 ms, así que el número de inicios de sesión nuevos se limita a unos 200 por núcleo de datos por segundo (medido: 308 a 342 en dos núcleos). La inundación en esa máquina no es un instrumento estable (de 20k a 440k entregados por segundo entre ejecuciones) y no sacamos conclusiones de ella. La comparación del camino en claro con Mosquitto en el VPS todavía no se ha hecho. Pruebas: el grupo de smoke plaintext 7 de 7 en aarch64 HVF y en x86_64 TCG, un nuevo objetivo de fuzz plain_input (2,3 millones de ejecuciones sin hallazgos).

Errores que encontró el uso en vivo

Dos cosas no las atraparon las pruebas, sino la primera puesta en marcha en el sitio real:

• La página buscaba los archivos de la versión un directorio más arriba de lo debido, así que toda comprobación de firma respondía 404 (corrección 13af301). La prueba usaba un espejo de prueba en otra ruta.
• El teclado del emulador nunca llegó al invitado: la causa no fue una mala traducción de teclas, sino que el diálogo no escuchaba las teclas en absoluto (corrección en el ADR-232, con una entrada de arranque que no necesita teclas).

Lecciones

• Busque la causa, no culpe al entorno. La mayor parte de las debilidades del flujo único y todas las conexiones cortadas eran nuestras; el hipervisor es real, pero había que medirlo, no suponerlo.
• La comparación con otro producto debe incluir también las pérdidas. Una tabla en la que solo están nuestras victorias no sería una comparación.
• El instrumento de medida tiene límites. Un generador compartido con 60 a 70 % de tiempo robado cambia lo que significan las cifras; por eso escribimos "límite inferior" y no afirmamos diferencias inferiores al 20 %.
• El aislamiento no es una prueba. SQLite en EL0 reduce lo que puede hacer un fallo en él, no aquello en lo que puede mentir.
• Una instalación real encuentra lo que las pruebas no piden: una ruta mal armada y teclas que nadie escucha.

Lo que aún no está demostrado

• La clave de firma de las versiones es por ahora una clave de prueba; v0.2.0 y v0.2.1 son pre-release, y las imágenes que las acompañan son de desarrollo con certificados de prueba (salvo la plantilla, que no tiene configuración).
• 13 traducciones de la página del constructor (y de este texto) las escribió una IA y las comprobaron pruebas y muestras, no hablantes nativos.
• La comparación con Mosquitto es una sesión, un camino y un generador compartido, en un VPS compartido; las diferencias inferiores al 20 % no son afirmaciones.
• El camino en claro no se ha medido en el VPS ni frente a Mosquitto.
• Lighthouse en la nueva vista sencilla no está confirmado (vista anterior: accesibilidad 95 o más).
• Bare metal, el coste del worker en x86_64 en KVM, Firefox y Safari para el emulador: no se ha medido.

Lo que viene

• D1: broker de demostración público. El emulador del navegador no lo podemos hacer público: vive en la pestaña de un visitante, es de 20 a 100 veces más lento que KVM, no tiene red entrante y desaparece al cerrar la pestaña; redirigir internet al navegador de otra persona sería además un abuso. Es posible un broker de demostración de verdad: urMQTT en un VPS detrás de un nombre en aldo.tech, con una CA de prueba publicada, una ACL estricta y límites pequeños. Por ahora es solo una idea, no una construcción, y necesita un consentimiento explícito para la exposición pública.
• Segunda ronda para el flujo único (rama perf-single-flow-wip): solo cuando esté medida en el VPS e integrada.
• El camino en claro frente a Mosquitto en el VPS, el alta y la revocación de cuentas para MQTT en claro a través de un canal de gestión firmado.
• Después de la publicación: bare metal (X12 a X16), IOMMU y Secure Boot, cifrado del disco.

El código está en github.com/zeljan-alduk/urMQTT, y docs/PROGRESS.md sigue siendo la única fuente de verdad sobre lo que realmente funciona, docs/PERFORMANCE.md sobre lo que se ha medido. Pre-alfa, como antes; los informes de errores y los avisos de seguridad según las instrucciones de SECURITY.md son bienvenidos.

Una advertencia previa: el proyecto sigue siendo pre-alfa. Las cifras del texto miden código y pruebas, no madurez en producción, y la primera publicación se limita deliberadamente a VPS con KVM. El bare metal queda para más adelante.

Cómo se vio en el tiempo

El primer commit se hizo el 28 de octubre de 2026 a las 23:48 (M0). El 31 de octubre a las 23:00 el repositorio tiene 119 commits, repartidos como 3, 39, 38 y 39 por día natural. Digamos enseguida cómo es posible: el proyecto se construye con Claude Code y los commits llevan trailers Co-Authored-By: Claude. Cuatro días naturales de historial no significan que una persona haya escrito 90 000 líneas en cuatro días; significan que el plan, la implementación, las pruebas y los ADR se escriben en bucles cortos y cerrados, y que cada paso termina con el mismo ritual de verificación de siempre. Las cifras de abajo hablan de la cantidad de código y de pruebas, no de cuánto trabajo real se invirtió en todo ello.

El gráfico muestra tres curvas que crecen casi a la par, que es justo la intención: las pruebas y las decisiones escritas acompañan al código y no se quedan atrás. La pendiente es más pronunciada el 29 de octubre, cuando se construye todo el camino desde el núcleo hasta el broker. Después las líneas se añaden más despacio, pero las pruebas crecen más rápido que el código (27 pruebas con 1,6 mil líneas al principio, 739 con 89,8 mil hoy).

Las líneas son todos los archivos .rs fuera de vendor/ y fuzz/, y las pruebas son funciones #[test]. Qué aportó cada tramo, según la fecha del historial de git:

Promesa 1: una ISO para varias plataformas

Qué habíamos planeado. Un único archivo que arranque en UEFI aarch64, UEFI x86_64 y BIOS x86_64. Qué construimos. El port a x86_64 (X0 a X10) y una ISO universal con el bootloader Limine, una ISO híbrida desde la que arrancan todas esas combinaciones; las pruebas de humo la arrancan en cuatro máquinas virtuales. El menú tiene tres entradas: urMQTT (modo en vivo, se ejecuta desde la RAM, no escribe nada en el disco), instalación en el disco de la máquina en la que se ejecuta (la instalación escribe GPT y datos y luego apaga la máquina) y Diagnóstico (detección de hardware y mediciones).

El primer objetivo real fue un VPS y no un ordenador físico: la decisión es que la primera versión admita solo VPS (KVM) y que el bare metal llegue después. Probamos en un VPS de Contabo con un procesador AMD EPYC (familia 23, Zen 1), 4 vCPU y 8 GiB de RAM, con red virtio-net y disco virtio-scsi. El primer intento nos sorprendió: la ISO conectada como CD virtual arrancó la entrada por defecto, la imagen de producción se negó a servir desde un medio de solo lectura y se reinició, y nos quedamos con un bucle infinito de menú, núcleo y reinicio sin nada legible. Hoy un error fatal en la imagen de producción deja un mensaje en la consola durante 60 segundos antes de reiniciar, y desde un medio óptico escribe que se arrancó desde un medio de solo lectura y se detiene. El modo en vivo en RAM (O3) acabó eludiendo ese problema en el caso habitual.

La entrada de diagnóstico nació de esa experiencia: a una máquina que no vemos tenemos que poder preguntarle qué tiene. Muestra la CPU, la RAM, la red, los discos y los dispositivos PCI, mide el ancho de banda de memoria, el disco y la criptografía, y escribe esas mismas mediciones como JSON en el puerto serie. La escritura en disco solo se permite en el espacio sin asignar y únicamente después de teclear WIPE; en la captura de abajo se omitió.

Lo que sigue abierto. El hardware real. Después de la primera versión viene el bare metal (arranque por USB, NVMe y AHCI, la tarjeta de red de un ordenador de verdad), junto con IOMMU y Secure Boot, porque sin IOMMU un dispositivo malicioso o defectuoso puede escribir en toda la memoria. En esta versión no afirmamos nada al respecto.

El handshake: de 1,2 ms a 0,24 ms

La primera medición del diagnóstico en el VPS dio una cifra incómoda: el handshake mTLS, solo la criptografía del lado del servidor, tardaba 1,2 ms. En aarch64 ya usábamos las instrucciones AES y SHA de hardware, pero x86_64 no tenía nada parecido para la clave pública: RustCrypto es portable y constant-time, y por eso también lento. Tres cambios lo bajaron.

• Para P-256 incorporamos el ensamblador nistz256 de OpenSSL y ring (ADR-130), con tablas de base fija para firmar y para verificar firmas de la CA (ADR-110, ADR-111).
• X25519 se reescribió con cuatro miembros de 64 bits y las instrucciones MULX/ADX (ADR-131).
• Después perfilamos también el resto (ADR-132, ADR-200).

Las cifras varían alrededor de un 10% entre ejecuciones, así que anotamos un rango en lugar de un único valor. En total son aproximadamente cinco veces menos tiempo de CPU por handshake.

Lo que aprendimos sobre memcpy. Cuando la criptografía bajó, el perfil mostró algo que no esperábamos: las funciones mem* (memcpy, memmove, memset) consumían el 7% del handshake, del 13 al 39% del camino del registro TLS (39% con 64 B, 13% con 4 KiB) y del 17 al 34% de la distribución de PUBLISH. Las sustituimos por ensamblador SSE2 para x86_64 (ADR-200), con pruebas diferenciales contra la implementación de referencia para todos los tamaños, alineaciones y solapamientos. Por llamada son de 55 a 75 ciclos frente a 7 a 12 para 1 a 64 bytes.

Cómo leer el gráfico: cuanto más pequeño es el registro, mayor parte del tiempo se va en copiar, y por eso la mejora es mayor. Para los mensajes pequeños, que son la mayoría del tráfico MQTT, eso es lo que cuenta.

Lo que esto no significa. En x86_64 nativo medimos OpenSSL 3.5.5 (ADR-130) solo como referencia para el ensamblador, no como comparación de productos. La comparación de Linux más Mosquitto en el mismo VPS (tarea X11) todavía no la hemos hecho. Por eso no afirmamos que urMQTT sea más rápido que Linux: no está medido. Las cifras de arriba comparan urMQTT consigo mismo.

La sobrecarga fue el segundo resultado. En el VPS, desde un solo Mac (RTT 35 ms), 128 clientes dieron 618 handshakes por segundo, 256 clientes 393 y 512 clientes 67, con miles de conexiones rechazadas. No fue una meseta sino un colapso. Encontramos las causas en el código (dos se confirmaron en QEMU/HVF y no pudieron reproducirse en el VPS), varias a la vez: una conexión rechazada devolvía al cliente, a través del siguiente segmento, una cookie SYN válida; el rechazo mediante RST le decía al cliente que lo intentara de nuevo de inmediato; y la recepción era O(cola). La corrección (ADR-080 a ADR-082) descarta el SYN que no sería aceptado, recuerda los flujos rechazados, mantiene la recepción en O(1) y cuenta los handshakes por núcleo. Es posible (hipótesis, sin verificar) que parte de la causa estuviera también en el cliente: la herramienta de carga cerraba primero, así que un Mac con 16 384 puertos efímeros y un TIME_WAIT de 30 segundos queda limitado a unas 550 conexiones por segundo. Por eso el techo real del servidor todavía no lo hemos medido.

Promesa 2: disco en bruto, pero con cuidado

Qué habíamos planeado. Mantener nuestra propia disposición sin sistema de archivos y añadir todo lo que un sistema de archivos suele dar: alineación, crecimiento, discard, copias de seguridad y comprobaciones. Por qué no un sistema de archivos. Lo discutimos y la decisión se confirmó: urMQTT escribe una base de datos, un registro de telemetría y sus propios metadatos, no necesita directorios, permisos ni nombres de archivo, y cada capa adicional sería más código en la parte de confianza y una manera más de que una escritura desaparezca en silencio. El disco es GPT con una partición ESP y una partición de datos de urMQTT, en la que está la disposición propia.

Qué construimos (S2 a S6).

• Disposición v2 (S2). Topología del disco, alineación a 1 MiB o al tamaño óptimo de E/S, bloques físicos completos, un par A/B de superbloques con generación (ADR-140). El núcleo rechaza la disposición v1 con un mensaje claro, y la migra la herramienta sin conexión urmqtt-disk migrate (ADR-141): por defecto es una pasada de prueba, se copia y solo entonces se conmuta, con reversión e inyección de fallos en cada escritura.
• Crecimiento (S3). Al arrancar el disco puede crecer (nunca se reduce), y en virtio-blk también durante el funcionamiento, mediante la interrupción de cambio de configuración (ADR-142, ADR-143).
• Discard y write-zeroes (S4). Los discos con aprovisionamiento ligero devuelven el espacio al anfitrión. En la prueba, el archivo qcow2 del anfitrión bajó de 62 a 16 MiB después de que expiraran los segmentos de telemetría, y la recuperación nunca confía en el contenido que se ha descartado.
• Copia de seguridad de la base en disco (S5). Copia A/B con la API de backup en línea de SQLite en pasos de 16 páginas: el paso más largo fue de 4,6 ms frente a 445 ms al copiar en una sola llamada. Los commits durante la copia tuvieron un máximo de 2,4 ms frente a 2,2 ms sin ella. Si quick_check falla al arrancar, la base se restaura desde la copia.
• Limpieza y arranque acotado (S6). El scrubber lee el disco con un presupuesto de E/S limitado e informa de los registros dañados, y el arranque lee solo el segmento más reciente de cada partición, de modo que el tiempo de arranque no crece con el tamaño de la región de telemetría. Con eso cerramos un problema que habíamos calculado de antemano: en un disco grande, la recuperación completa tardaría de minutos a decenas de minutos.

Todo el grupo de pruebas de humo de almacenamiento pasa en ambas arquitecturas: 79 correctas, 0 fallidas, en aarch64 bajo HVF y en x86_64 bajo TCG. También medimos que S4 no ralentizó la base: 53,3 mil inserciones por segundo en lotes antes y después, sin diferencia medible.

Lo que nos sorprendió. Cuánto de una disposición "sencilla" son casos límite: virtio-scsi y virtio-blk informan de la topología de maneras distintas, y una escritura incompleta a mitad de la migración debe dejar siempre al menos una versión válida. Por eso cada escritura en el camino de la migración y del crecimiento pasó por inyección de fallos.

Lo que sigue abierto. Las páginas de SQLite no tienen suma de comprobación, de modo que la base no detectará un bit cambiado dentro de un valor de una fila; los registros de telemetría y el contenido de las copias tienen CRC y sí se detectan. El cifrado de disco (S7) no está terminado.

Promesa 3: demostrablemente seguro, hasta donde lleguemos

Refuerzo (H4). El asignador borra la memoria liberada y la verifica al reutilizarla, detecta la doble liberación, enlaza los punteros de la lista libre con XOR y pone a cero las claves al liberarlas (ADR-170). Protección de pila (-Zstack-protector=strong, 1315 funciones, y SQLite con -fstack-protector-strong, ADR-171). Los informes de errores en producción no contienen registros ni direcciones (ADR-172). KASLR en ambas arquitecturas: el núcleo es PIE y Limine lo desplaza unos 19 bits, y el heap, las pilas y la ventana MMIO se colocan al azar (ADR-173). En aarch64 MTE etiqueta el heap (ADR-174), pero solo bajo TCG: HVF y x86 no lo tienen. Evaluamos kCFI y no lo adoptamos porque el compilador del nightly fijado falla con un error interno; IOMMU se pospuso junto con el bare metal (ADR-175, ADR-176).

El coste está medido, no supuesto. En el camino del handshake (dp-bench, aarch64 HVF, handshakes completos de TLS 1.3 + mTLS + CONNECT):

En total, el coste en el camino del handshake es de aproximadamente el 5% para las piezas medidas limpiamente, y con PIE y etiquetas sale alrededor del 7% con un núcleo y alrededor del 11% con cuatro, pero esa medición tiene ruido. La consideramos aceptable, pero no la hemos repetido en el VPS x86_64.

Conviene compararlo con la cifra del primer texto (862 handshakes por segundo con un núcleo). La misma herramienta hoy, con el cifrado por hardware activado en aarch64 (X0b) y una serie de aceleraciones llegadas desde entonces, da 1941 antes del refuerzo. No aislamos la contribución de cada cambio, así que no afirmamos nada sobre la causa.

Cómo se verificó, y qué no. H5 añadió Miri sobre un subconjunto de crates del host, pruebas de Kani, sanitizers, un model-fuzzer para la ACL e informes de cobertura. Kani demostró record_len en TLS, parse en TCP y dos aritméticas de la rueda de temporizadores. No se demostró (tiempo agotado): los dos decodificadores MQTT, los dos análisis de configuración y el comportamiento de la rueda de temporizadores; por eso el trabajo de CI de Kani todavía no bloquea. Miri no puede ejecutar ensamblador. Cadena de suministro (H9): SBOM CycloneDX con 215 componentes, cargo-vet pasa con 39 totalmente auditados y 140 excepciones, y cargo-deny está configurado para tratar los avisos de vulnerabilidades como fallo de CI (esos trabajos de CI hasta ahora se han comprobado solo en local, no en GitHub, y la prueba negativa no se ha ejecutado), junto con VULNERABILITY-HANDLING.md. El estado sincero: de 67 versiones de crates de terceros enlazadas en el núcleo, 53 son excepciones y no auditorías. Vet demuestra que el conjunto de dependencias no puede cambiar sin una diferencia visible, no que la TCB esté revisada. No hemos escrito una auditoría propia de ningún crate.

SNTP (T1) es en ese sentido una pequeña historia de seguridad: es opcional, solo hacia servidores IPv4 privados, con un salto máximo y la condición de que las fuentes coincidan (mediana, mayoría dentro de un segundo). Un reloj que cualquiera en el camino puede mover no es un reloj en el que podamos confiar para la validez de los certificados.

En el Mac: aarch64 de forma nativa y x86_64 por emulación

Desarrollamos en un Mac, y este tiene dos maneras de ejecutar el mismo código que son muy distintas.

La regla es sencilla: las cifras bajo TCG son emulación y no las citamos como rendimiento. El rendimiento de x86 lo medimos solo en un VPS real. Por eso las cifras de criptografía de arriba vienen del VPS de Contabo y no del Mac.

Lecciones

• Mida en una máquina real antes de optimizar. Nuestro primer enfoque fue optimizar lo que creíamos lento; solo el diagnóstico en el VPS mostró los 1,2 ms y por dónde se iba exactamente el tiempo.
• La sobrecarga es una característica aparte. Un sistema que es rápido bajo carga puede colapsar por encima de ella; rechazar debe ser más barato que aceptar.
• El perfil sorprende. La mayor mejora individual para los mensajes pequeños no estuvo en la criptografía sino en la copia de memoria.
• Un disco sin sistema de archivos exige más trabajo, no menos. Lo que un sistema de archivos suele dar (alineación, crecimiento, discard, copias, comprobaciones) tenemos que escribirlo y verificarlo nosotros, cada paso con inyección de fallos.
• Honestidad en las cifras. Las mediciones de memoria en un VPS compartido varían hasta 10 veces entre ejecuciones y no dicen nada sobre el código, así que no las citamos. Las cifras de criptografía son estables hasta aproximadamente el 10%.
• La velocidad de desarrollo no es madurez. Las pruebas y los ADR crecen junto con el código, pero cuatro días no son un entorno de producción real.

Lo que viene

• H6: SQLite aislado a nivel EL0, para que un error en la base de datos no abra el núcleo.
• H7: el resto de la seguridad del tiempo (NTS y tratamiento de saltos); SNTP es solo el primer paso.
• X11: comparación con Linux y Mosquitto en el mismo VPS; solo entonces tiene sentido hablar de velocidad relativa.
• Versión: la primera publicación pública para VPS (KVM), con artefactos firmados e instrucciones.
• Después de la versión: bare metal (X12 a X16), IOMMU y Secure Boot, y cifrado de disco.

El código está en github.com/zeljan-alduk/urMQTT, y docs/PROGRESS.md sigue siendo la única fuente de verdad sobre lo que realmente funciona. Pre-alfa, como antes; los informes de errores y los avisos de seguridad, según las instrucciones de SECURITY.md, son bienvenidos.

Así nació urMQTT: un unikernel que es un broker MQTT. Núcleo, TCP/IP, TLS 1.3, MQTT y una base de datos integrada en un único binario de Rust que arranca desde una sola ISO. No hay procesos, ni llamadas al sistema, ni shell. La primera plataforma en la que se construye y se prueba es aarch64, y el mismo código avanza hacia x86_64, tanto por UEFI como por BIOS clásico, y hacia hardware real: el objetivo es una única ISO que arranque en todos ellos. El proyecto es de código abierto, con licencia MIT o Apache 2.0, y en este texto queremos dejar constancia de dónde estamos, de cómo está organizado por dentro y de lo que hemos aprendido por el camino.

Qué significa exactamente "unikernel"

Un broker habitual es un programa que se ejecuta sobre un sistema operativo. urMQTT no tiene ningún sistema operativo debajo: arranca por sí mismo a través del firmware UEFI y del bootloader Limine, configura sus propias tablas de páginas, programa el controlador de interrupciones y el temporizador, encuentra los dispositivos virtio a través de PCIe, obtiene una dirección por DHCP y escucha en un único puerto. Todo lo que normalmente harían el núcleo, los controladores, la pila de red y la aplicación es aquí un único ELF que se ejecuta en el nivel EL1.

La comparación con una instalación típica habla por sí sola:

Las prioridades son, por este orden: seguridad, escalabilidad, rendimiento multinúcleo, huella reducida e instalación inmutable. Siempre que dos objetivos entran en conflicto, gana el que está más arriba en esa lista.

Dónde estamos ahora

El proyecto está en fase pre-alfa, pero se han cerrado diecisiete hitos de desarrollo, de M0 a M17. Hoy urMQTT atiende MQTT 3.1.1 sobre TLS 1.3 con certificados de cliente obligatorios, y guarda el estado en SQLite sobre un disco en bruto. En resumen, esto es lo que ya funciona:

• Núcleo: vectores de excepción propios con informes decodificados, tablas de páginas propias con W^X aplicado, páginas de protección, PAC y BTI donde el procesador los tiene, GICv3 y GICv2, temporizador genérico, SMP hasta 64 núcleos.
• Detección de hardware a partir de DTB o ACPI en una única descripción de plataforma, con un resultado idéntico desde ambas fuentes.
• Controladores: PCIe ECAM, MSI-X, virtio-net, virtio-blk, virtio-scsi y virtio-rng, además de un CSPRNG sembrado con entropía de hardware.
• Red: DHCPv4, ARP, ICMP e IPv4 estricto propios, y un TCP propio solo para el lado servidor: cookies SYN, rueda de temporizadores jerárquica, NewReno, fusión de ACK, sin estado TIME_WAIT.
• TLS: solo TLS 1.3, mTLS obligatorio, identidad del dispositivo a partir del CN o del URI del SAN; el handshake lo realiza rustls y, después, una capa de registros propia con AES-128-GCM y ChaCha20-Poly1305. Reanudación de sesión con tickets PSK, lista de revocación, control de admisión ya en el handshake.
• MQTT: códec sin copias, con fuzzing y probado con clientes mosquitto reales; QoS 0 y 1, comodines, mensajes retenidos, testamento (LWT), sesiones persistentes, ACL limitada a devices/{id}/#, límites de tasa por dispositivo.
• Almacenamiento: SQLite dentro del núcleo mediante un VFS sobre el disco en bruto, en modo WAL, con comprobación de integridad al arrancar; registro de dispositivos, revocaciones, mensajes retenidos, sesiones persistentes con colas de mensajes para los dispositivos que están desconectados; por cada núcleo, un registro de telemetría independiente con CRC por entrada y recuperación tras una caída.
• Operación y supervisión: temporizador de vigilancia para los manejadores, comprobación de salud, registro limitado, syslog y statsd sobre UDP, una admisión que sobrevive a las tormentas de reconexión.
• Entrega: reconstrucciones idénticas bit a bit verificadas en CI, ISO e imagen de disco GPT en bruto, firmas minisign, instrucciones para KVM, Proxmox y Hetzner.

Cada paso está marcado con el hito que lo aportó, y el archivo docs/PROGRESS.md del repositorio es la única fuente de verdad sobre lo que realmente funciona.

La arquitectura en tres imágenes

Todo el diseño está descrito en docs/ARCHITECTURE.md, y las razones de cada decisión importante están registradas como ADR en docs/DECISIONS.md. Aquí tiene un resumen.

Las capas

De arriba abajo: el broker (sesiones, árbol de temas, QoS, mensajes retenidos, testamentos, ACL, límites), el códec MQTT, TLS, TCP, la capa de red y, por último, los controladores. Junto a ese camino principal están el almacenamiento (SQLite y el registro de telemetría) y, debajo de todo, la gestión de memoria, la detección de la plataforma y la configuración, que se traduce a constantes en tiempo de compilación, junto con el certificado de CA incorporado, el certificado del servidor y la clave. El hipervisor con los dispositivos virtio es lo único que queda fuera de la imagen.

Un hilo por núcleo, sin estado compartido

Cada núcleo de datos hace girar su propio bucle con su propia pila TCP, sus estados TLS, una parte del broker (sesiones y árbol de temas), una caché del heap y una partición de telemetría. Los núcleos no comparten ningún estado mutable, solo anillos acotados y sin cerrojos, uno por cada par ordenado de núcleos. El núcleo más alto ejecuta SQLite y nada más.

La tarjeta de red tiene hoy un único par de colas, que mantiene el núcleo 0. Este dirige cada flujo MQTT, según el hash Toeplitz de su cuádruple, hacia uno de los núcleos de trabajo y envía lo que los núcleos de trabajo devuelven. La sesión vive en su núcleo de origen, determinado por el hash del identificador de cliente, de modo que la toma de control, los testamentos y la durabilidad no cruzan nunca de un núcleo a otro. Una conexión que aterriza en otro núcleo conserva allí su TCP y su TLS, y reenvía el MQTT en claro al núcleo de origen con un control de flujo basado en créditos. Cada mensaje enrutado se distribuye además a las demás partes del broker, cada una de las cuales mantiene una réplica de los mensajes retenidos.

Tres reglas mantienen unido este modelo. Procesamiento hasta el final: un paquete recibido se procesa por completo en un único núcleo, desde TCP, pasando por el descifrado de TLS en el sitio, el análisis de MQTT y el enrutamiento, hasta la respuesta cifrada, sin colas de tareas y sin copias a búferes de la aplicación. Sondeo adaptativo: bajo carga las colas de recepción se sondean activamente, y en reposo el núcleo vuelve a las interrupciones y a WFI; los manejadores de interrupciones solo reconocen la interrupción y marcan el trabajo. Temporizador de vigilancia: un pulso de 10 ms por núcleo atrapa a los manejadores que superan su presupuesto.

La vida de un PUBLISH

El dispositivo envía un registro TLS. La tarjeta de red lo entrega al bucle del núcleo mediante un descriptor, sin copias. El bucle comprueba TCP, descifra TLS en el sitio y analiza MQTT desde el búfer prestado; después, en memoria, comprueba la ACL, el límite de tasa y la ruta por el árbol de temas. Si a otro núcleo le interesa ese tema, recibe un mensaje de enrutamiento con una referencia al contenido y el identificador del tema; la base de datos recibe un registro de telemetría o la actualización de un mensaje retenido, por lotes. La respuesta PUBACK se cifra directamente en el búfer de salida y se fusiona con el ACK de TCP, de modo que al dispositivo le sale un solo segmento. Al otro núcleo, el mensaje le cuesta un cifrado por suscriptor en el momento del envío.

Cuánto cuesta una conexión

El objetivo es como máximo 512 bytes por conexión TLS inactiva, con la aspiración de llegar a 256. Mientras la conexión está en reposo no se guarda nada para ella en búferes: los datos recibidos se procesan directamente desde la trama de red, y los búferes de envío, de registros y de MQTT existen solo mientras haya algo inacabado o sin confirmar. El propio núcleo lo mide: contadores exactos del heap, tanto en bytes solicitados como en los bloques que ocupan, anotados cada diez segundos como heap por encima del nivel base por conexión abierta.

Medido bajo HVF con cuatro núcleos virtuales, tres de ellos de trabajo, con cada dispositivo manteniendo una conexión mTLS y una suscripción con QoS 1, incluido el redondeo del asignador:

El pool de tramas de red es fijo, de unos 2 MiB, lo que equivale a unos 200 B por conexión con diez mil conexiones y a unos 2 B con un millón. No pudimos medir más allá: la red de usuario de QEMU en macOS dejó de aceptar conexiones en 10 197, aproximadamente en el límite de 10 240 descriptores del proceso de QEMU. La cifra baja a medida que las partes fijas se reparten entre más conexiones, por lo que no crece con su número.

Modelo de seguridad

La seguridad es la prioridad número uno y gana todos los conflictos con los demás objetivos. El modelo tiene varias capas:

• Un solo puerto. TCP 8883, solo TLS 1.3, certificados de cliente obligatorios firmados por la CA incorporada en la imagen. El identificador de cliente MQTT debe ser igual al identificador de dispositivo del certificado.
• Sin puntos de entrada. Sin shell, sin entrada por consola, sin SSH, sin API de administración, sin código dinámico, sin SQL accesible por la red y sin sistema de archivos.
• Seguridad de memoria. Rust, con forbid(unsafe_code) en los paquetes de protocolo; cada bloque unsafe lleva un comentario // SAFETY: que verifica un lint, y ante entradas externas no hay pánicos: clippy prohíbe unwrap, expect, la indexación y panic! en los paquetes de la ruta de datos.
• Mitigación de la explotación. W^X se aplica mediante la codificación de descriptores y el bit SCTLR_EL1.WXN, y se audita en cada arranque. Tras el arranque, las tablas de páginas son de solo lectura, sin alias escribible. La mitad inferior del espacio de direcciones queda excluida. Cada pila tiene páginas de protección y las excepciones se ejecutan en una pila aparte. PAC y BTI se activan cuando el procesador los admite, y las pruebas de humo lo comprueban.
• Resistencia al abuso. Cookies SYN; la admisión rechaza nuevas conexiones, antes de cualquier criptografía, cuando el heap está bajo, cuando la base de datos se retrasa, cuando hay demasiados handshakes en curso por núcleo o por dirección de origen, o cuando la tasa de handshakes es demasiado alta. Límites de tasa por dispositivo, colas acotadas, ventana TCP ligada a la contrapresión del broker, registro limitado, temporizador de vigilancia y comprobación de salud.
• Inmutabilidad. La configuración, la CA y la clave del servidor están incorporadas en la imagen. Cambiar cualquiera de ellas significa una imagen nueva.

El modelo de amenazas está recogido en docs/SECURITY.md.

Almacenamiento sin sistema de archivos

Los datos viven en un disco aparte, virtio-blk o virtio-scsi, en el que no hay sistema de archivos. La disposición es mínima y propia:

LBA 0      [ superbloque: magia · versión de la disposición · uuid · tabla de regiones · CRC-32C ]
LBA 8, 16  [ tabla de tamaños de archivo, ranuras A/B (gana la última válida) ]
LBA 64     [ base principal de SQLite ½ ][ WAL de SQLite ⅛ ][ diario 1 MiB ][ registro de telemetría: 8 particiones … ]
últimos 4 KiB [ espacio para la autocomprobación del dispositivo de bloques al arrancar ]

SQLite (3.54.1 vendorizado, con verificación del resumen en la compilación) se compila dentro del núcleo con clang, sin biblioteca estándar, y utiliza un heap memsys5 fijo. Su VFS asigna tres archivos fijos a regiones del disco. Funciona en modo WAL con locking_mode=EXCLUSIVE, por lo que no necesita un índice en memoria compartida, y con synchronous=FULL; si quick_check encuentra un error al arrancar, el sistema se detiene de forma segura. En la base de datos están el registro de dispositivos, las revocaciones, los mensajes retenidos y las sesiones persistentes con colas de mensajes QoS 1 para los dispositivos que no están conectados.

El núcleo de la base de datos, el que tiene el número más alto, ejecuta SQLite y nada más. El plano de datos le envía los cambios de estado a través de un anillo SPSC sin cerrojos; este los agrupa en una transacción cada 5 ms o cada 512 operaciones y devuelve las confirmaciones por otro anillo. Un disco vacío se formatea en el primer arranque; en cualquier otro caso, nunca se formatea encima.

La telemetría sigue otro camino. Cada PUBLISH aceptado en los temas de storage.telemetry_topics va a la partición del registro de telemetría de su núcleo: un anillo de segmentos con CRC por entrada, salado con la secuencia del segmento, de modo que las pasadas antiguas del anillo no reaparezcan nunca. Los núcleos entregan las entradas a la base de datos mediante su propio anillo, sin copias, y esta las escribe cada 5 ms o cada 256 KiB. Al arrancar, la recuperación conserva cada entrada escrita, recorta la cola incompleta y continúa en un segmento nuevo. La retención es por tamaño, a través del anillo, y por antigüedad, mediante retention_days. Lo verificamos con un millón de entradas y con kill -9 en mitad de la escritura.

Las cifras

La herramienta de carga de tools/loadgen hace tres cosas: una tormenta de handshakes TLS 1.3 con mTLS y CONNECT, conexiones de larga duración con PINGREQ que publican telemetría cada segundo, y tormentas de reconexión. make bench en un Apple M4 Pro bajo HVF da:

La cifra en el invitado, donde el cliente y el servidor están dentro de la misma máquina virtual y cada núcleo de trabajo funciona por su cuenta, muestra que el plano de datos escala de forma lineal. La cifra de red está limitada por la red de usuario de un solo hilo de QEMU, no por el invitado; y así consta en el ADR-032.

Probamos las tormentas de reconexión haciendo que todos los dispositivos se conecten a la vez, repitan con espera los intentos rechazados y luego caigan todos sin DISCONNECT. El parámetro heap_limit_mb= en el modo de desarrollo hace que la admisión considere el heap más pequeño de lo que es, de modo que una tormenta mayor que el heap puede probarse con pocos sockets. En una de esas rondas con 3 000 dispositivos, se conectaron 1 368 en 36 segundos y 5 619 intentos fueron rechazados de forma ordenada, con un límite de 8 MiB; la memoria se recuperó tras la tormenta.

Cómo trabajamos

El proyecto se guía por una especificación escrita, PROMPT.md, con un plan de hitos, y cada hito termina con el mismo ritual: make check y make smoke en verde, un commit con la etiqueta M<n>, una entrada en docs/PROGRESS.md y un ADR para cada decisión que no sea obvia. Las reglas son breves y no negociamos sobre ellas: sin pánicos ante entradas externas, unsafe solo en los paquetes de hardware y FFI y siempre con comentario, sin asignaciones en la ruta caliente, un comentario junto a cada orden de operaciones atómicas, cada límite procede de la configuración, y las piezas provisionales deliberadas fallan de forma ruidosa.

El CI hace más de lo que podríamos hacer a mano: fmt, clippy para el host y para aarch64-unknown-none, typos, actionlint y shellcheck; pruebas en Linux y en macOS sobre arm64; compilación del núcleo para la configuración de desarrollo y la de producción con el tamaño del ELF en el resumen; arranque bajo QEMU con todos los escenarios de la prueba de humo y almacenamiento de los registros serie; cargo-deny para avisos, licencias y fuentes; un minuto de fuzzing por cada uno de los once objetivos y, por la noche, diez minutos por objetivo con un corpus en caché. Además, CodeQL, OpenSSF Scorecard, Dependabot y una publicación con procedencia SLSA. Cada acción de terceros está fijada al SHA completo del commit.

Entendemos la reproducibilidad de forma literal: make repro compila HEAD dos veces en árboles de trabajo nuevos y compara el ELF, la ISO y la imagen en bruto byte a byte. Las versiones publicadas están firmadas con minisign, y los artefactos pueden verificarse con gh attestation verify. La imagen de producción contiene la clave privada del servidor, por lo que la ISO misma es un secreto; las imágenes que acompañan a las versiones en GitHub son de desarrollo, con claves temporales, y sirven solo para probar.

Lo que hemos aprendido

Algunas lecciones que cambiaron el plan:

• Un TCP propio terminó mereciendo la pena. El prototipo funcionó sobre smoltcp y nos sirvió bien hasta M13. Pero un servidor que mantiene cientos de miles de conexiones no necesita un TCP de cliente, necesita cookies SYN, una rueda de temporizadores y un estado de 96 bytes. En M14 sustituimos smoltcp por una pila propia solo para el lado servidor, con pruebas de pérdida simulada y fuzzing de segmentos.
• Mida la memoria desde dentro. Las estimaciones por conexión eran inútiles hasta que el núcleo empezó a contar el heap en bloques del asignador y no en bytes solicitados. Solo entonces vimos adónde van realmente los 512 bytes y bajamos hasta 494.
• La herramienta de pruebas forma parte del producto. La mayor limitación no fue el núcleo, sino la red de usuario de QEMU y el número de puertos efímeros del equipo de desarrollo. Para cien mil conexiones o más se necesita vmnet-shared en macOS o Linux con KVM, una interfaz tap y varias direcciones de cliente.
• SQLite sin sistema operativo es posible, pero solo con condiciones estrictas: un heap fijo, bloqueo exclusivo sin memoria compartida, un VFS que no sabe de archivos y una admisión que no deja que la base de datos se retrase.
• Las tormentas de reconexión son el estado normal, no la excepción. Cuando la red móvil se cae y vuelve, miles de dispositivos llaman a la puerta al mismo tiempo. Por eso la admisión rechaza la conexión antes de cualquier criptografía, y cada conexión rechazada cuesta casi nada.

Lo que viene

El trabajo posterior a M17 está planificado en tres direcciones, y el orden entre ellas está recogido en docs/PLAN.md. Nada de esto está construido todavía.

• Una ISO para varias plataformas. El mismo archivo urmqtt-<env>-<versión>.iso y una sola imagen GPT en bruto que arrancan en UEFI aarch64, UEFI x86_64 y BIOS x86_64, en máquinas virtuales y en hardware real, empezando por un PC Intel. Siempre un appliance con todo dentro, reproducible y firmado.
• Disco en bruto, sin sistema de archivos. Una especificación del formato a nivel de byte, la herramienta de host urmqtt-disk que comparte los analizadores con el núcleo, alineación de las regiones a 1 MiB, crecimiento del disco con los datos, discard para discos con aprovisionamiento ligero, instantáneas A/B de la base de datos, verificación de bits y, opcionalmente, cifrado AES-256-XTS con AES por hardware.
• Seguridad demostrable. Revocación y lista de dispositivos permitidos en tiempo de ejecución mediante un canal de control firmado, sin imagen nueva; pruebas diferenciales y de conformidad de nuestro propio TLS y TCP; KASLR, protección de pila, kCFI, MTE y un asignador reforzado; SQLite aislado en el nivel EL0; Secure Boot; SBOM y cargo-vet; y, por último, un paquete para una auditoría externa.

Las plataformas que ofrecen solo dispositivos que no son virtio, como AWS ENA o Azure MANA, por ahora no son compatibles. Raspberry Pi 4 y 5 como anfitrión KVM, Hetzner CAX y Oracle Ampere A1 están documentados y soportados en el código, pero aún no se han probado en un servicio real.

Pruébelo

El repositorio está en github.com/zeljan-alduk/urMQTT. Con Rust con la cadena de herramientas nightly fijada y QEMU, make certs, make run y un cliente mosquitto bastan para el primer PUBLISH sobre mTLS en su propio equipo. La advertencia del principio vale también al final: esto es pre-alfa, y todo lo que funciona figura en docs/PROGRESS.md. Los informes de errores, las preguntas sobre el diseño y los avisos de seguridad, según las instrucciones de SECURITY.md, son bienvenidos. Le informaremos aquí de cada nuevo hito.

En este blog anotamos lo que hemos aprendido por el camino. Nada de textos de marketing, sino notas concretas: qué salió mal, cómo lo resolvimos y qué haríamos distinto hoy.

Sobre qué escribiremos

• Cobro de billetes en el transporte público. Tarjetas sin contacto, módulos SAM, funcionamiento sin red y todo lo que un terminal tiene que aguantar en un vehículo que vibra doce horas al día.
• Aplicaciones móviles sobre el terreno. Android y Flutter en dispositivos que no son teléfonos corrientes: con lectores de tarjetas, impresoras y baterías que deben durar un turno entero.
• Backend y supervisión de flotas. Cómo saber que un dispositivo del vehículo tiene un problema antes de que lo avise el conductor.
• Hardware. Del prototipo en la mesa a la placa que entra en producción en serie, y todos los errores intermedios.
• Modelos de IA en local. Dónde tienen sentido los modelos en hardware propio y dónde la nube y una API son sencillamente la mejor opción.

Cómo escribiremos

Breve y concreto, con código y cifras cuando las tengamos. Publicaremos cuando tengamos algo que decir, no según un calendario. Las entradas se escriben en croata y se traducen a todos los idiomas de este sitio; también puede seguirnos por RSS.

Si le interesa algún tema o trabaja en un problema parecido, escríbanos a info@aldo.tech.