# NVIDIA publica Boro, un CLI en Rust con IA para auditar el kernel Linux > NVIDIA publica Boro, un CLI en Rust con IA local que revisa, compila y arranca parches del kernel de Linux sin salir del árbol de Git. > Por José Maldonado · Tecnología · 2026-10-16 NVIDIA lleva meses desarrollando una herramienta para que los programadores del kernel de Linux revisen sus parches sin salir de su propio árbol de Git. Se llama Boro, está escrita en Rust, se distribuye bajo licencia Apache 2.0 y la lidera Andrea Righi, ingeniero de la compañía. Righi la presentó en la [Linux Plumbers Conference](https://lpc.events/), que la ciudad de Praga acogió entre el 5-7 de octubre de 2026. La inspiración tiene nombre propio. Desde hace meses, [Sashiko](https://observatorioblockchain.com/ciberseguridad/sashiko-ia-revisa-kernel-no-time-to-pwn/), la herramienta de revisión con IA impulsada desde Google, examina las series de parches que llegan a las listas de correo del kernel y deja comentarios que los propios maintainers han recibido bien. Boro comparte los mismos prompts de revisión, pero apunta a otro momento del ciclo: el trabajo local previo a publicar, y el mantenimiento de kernels de distribución que nunca pasa por el proceso estándar de las listas. Ese matiz importa porque toca un punto sensible. El kernel de Linux es uno de los últimos grandes proyectos donde la vía oficial sigue siendo el correo electrónico, y cualquier herramienta que automatice el criterio técnico se mira con lupa. Que NVIDIA publique el código cambia el marco: Boro no es un servicio cerrado al que enviar los parches, sino un binario que cada desarrollador ejecuta contra su propio modelo, en su propia máquina, con su propio tokenizador y su propia factura. ## Un revisor que trabaja antes de que el parche sea público La diferencia entre Boro y Sashiko no está en lo que revisan, sino en cuándo lo revisan. El propio [README del repositorio](https://github.com/NVIDIA/boro) lo explica sin rodeos: Sashiko está optimizado para revisar series **después** de que aparezcan en las listas públicas de correo, mientras que Boro está optimizado para la revisión y reparación interactiva mientras el desarrollador todavía está dando forma a la serie o la arrastra por su cuenta. El caso de uso que justifica la herramienta es el mantenimiento de kernels de distribución. Cuando un equipo de Canonical, Red Hat o SUSE tiene que llevar un parche de seguridad desde la rama principal hasta un kernel de hace tres años, el proceso no pasa por las listas. Se hace en local, con cherry-picks que a menudo no aplican limpio, y con muy poca red de seguridad automática. Ese es el terreno que Boro quiere cubrir. Ahí Sashiko no encaja por diseño, porque su arquitectura está pensada para revisar series que ya se han publicado. El reparto de responsabilidades entre las dos herramientas es lo que hace que convivan en lugar de competir: una filtra lo que llega a la lista pública y la otra atrapa los problemas antes de enviarlo, que es donde el coste de corregir es menor. En la [charla que presentó en el LPC 2026,](https://lpc.events/event/20/contributions/2599/) Righi fue explícito sobre el diagnóstico. Su argumento es que el diseño de Sashiko está pensado para la interacción en la revisión ascendente, lo que lo hace menos natural cuando se aplica a flujos más iterativos o volcados en el downstream, como revisar backports en local o seguir los cambios que vienen de arriba. ## Conociendo las capacidades de Boro Boro se organiza alrededor de cuatro verbos. La revisión es el corazón, pero la compilación y el arranque son lo que separa esta herramienta de un simple envoltorio de chat sobre `git diff`. Subcomando Qué hace `boro review RANGO` Revisión multi-etapa del rango de commits con prompts por subsistema y resumen final en estilo LKML `boro build RANGO` Saca cada commit a su propio worktree, lo compila con `vng -b` y pide al modelo que triage el log `boro test RANGO` Igual que `build`, arranca el kernel bajo virtme-ng y lanza una prueba dirigida elegida por el modelo `boro apply RANGO` Cherry-pick asistido que intenta resolver los conflictos que no aplican limpio `boro apply --message-id ID` Descarga una serie publicada con `b4` y la aplica entera, de más antigua a más reciente La revisión se apoya en un conjunto de prompts específicos por subsistema que viven en el repositorio. Hay notas para memoria con fichas separadas por tipo: folios, reclamación y tablas de páginas. También las hay para `bpf, io_uring, drm, rcu, scheduler, tracing, vfs, wireless` y `rust`, entre una treintena de áreas en total. El modelo no revisa el parche en abstracto: recibe las convenciones concretas del área que toca. Los modos de compilación y prueba son los que justifican ejecutar esto en la máquina del desarrollador en vez de mandarlo a un servicio en la nube. Boro alimenta al modelo con la salida real del compilador y con la salida real del kernel en ejecución, no solo con el texto del diff. El flujo de `test` arranca la imagen bajo `virtme-ng` y lanza una prueba rápida seleccionada por el modelo entre un kselftest que encaje, una sonda en espacio de usuario sobre el código tocado o, como último recurso, `dmesg`. ## Una herramienta que no es solo para el kernel La estructura de prompts del repositorio revela una ambición mayor que la de revisar parches de Linux. Junto a la carpeta `resources/prompts/kernel/` conviven dos juegos completos más, uno para `libvirt` y otro para `qemu`, con sus propias notas de subsistema, guías de falsos positivos, escalas de severidad y plantillas de informe. El patrón se repite: revisión de estilo, patrones técnicos, notas por área y una escala de severidad propia. Libvirt llega con notas para cgroups, CPU, configuración de dominios, eventos, dispositivos de host, bloqueo, red, almacenamiento y seguridad, además de sus propias guías de falsos positivos. QEMU cubre ARM, bloque, chardev, KVM, firmware, memoria, migración, red, PCI y QAPI, con el mismo esquema de severidad por área. Eso sugiere que Boro se diseñó como un armazón extensible y no como un encargo puntual para el kernel. Quien quiera adaptarlo a otro proyecto de software libre solo tiene que escribir el juego de prompts correspondiente, porque el motor de etapas, el reparto entre modelos y la contabilidad de tokens ya están resueltos. ## El cherry-pick que se defiende solo La parte más llamativa del proyecto es la aplicación asistida de parches. Cuando un cherry-pick falla porque el código ha divergido, Boro no se detiene. Para los conflictos de diff3 que quedan, el modelo principal propone una resolución por cada conflicto y un segundo modelo, el validador, la aprueba o la rechaza. Los rechazos vuelven al modelo principal con el motivo concreto, hasta diez rondas por cada fragmento en conflicto. Cuando todos los fragmentos pasan la validación, Boro reescribe los archivos y los indexa. Después continúa el cherry-pick y actualiza el trailer `-x` de Git para que diga `(backported from commit ...)` en lugar de la referencia original. Después de la revisión posterior a la aplicación ejecuta una comprobación de solo código fuente sobre los nuevos accesos a campos de estructura y marca posibles huecos del backport. Si esa comprobación falla, el modelo validador recibe el problema exacto, puede editar el archivo y enmendar el commit. Ese ida y vuelta entre dos modelos es la decisión de diseño más interesante del proyecto, y también la que más discusión va a generar. Aprobar automáticamente la resolución de un conflicto en código de kernel significa aceptar que un modelo tiene la última palabra sobre semántica de bajo nivel. ## Dos modelos, dos facturas El reparto de trabajo entre modelos es explícito y está pensado para controlar el coste. `BORO_MODEL` se encarga de las etapas de descubrimiento general y de especialista, que son las que más tokens queman y las que menos precisión necesitan. `BORO_VALIDATION_MODEL` asume la revisión rápida de contexto completo, la validación de los candidatos nuevos que salen de la etapa general y la redacción del informe final. La combinación recomendada es la que se deduce de esa separación: un modelo local barato para el barrido amplio y un modelo remoto más capaz para la línea base protegida, la validación y el informe. El resumen de cada ejecución desglosa el consumo de tokens por etapa, así que se puede ver dónde se ha ido el presupuesto. Existe además un modo `--fast` que hace que la revisión rápida inicial use el modelo principal en vez del validador. En cuanto a los proveedores, Boro no ata a nadie. Funciona contra cualquier endpoint compatible con la API de chat de OpenAI mediante tres variables de entorno (`BORO_URL`, `BORO_KEY` y `BORO_MODEL`), y trae backends locales para Claude, OpenCode y Codex. Quien no tenga capacidad de cómputo para un modelo local puede apuntar a un servidor remoto compatible. ## Probando sus capacidades Los requisitos son pocos pero específicos. El comando que descarga series publicadas necesita [b4](https://b4.docs.kernel.org/) en el `PATH`, y los modos de compilación y prueba necesitan [virtme-ng](https://github.com/arighi/virtme-ng), la herramienta que Righi mismo mantiene. Para la etapa de seguimiento ascendente hace falta `lei`, del paquete public-inbox, aunque sin ella Boro ejecuta el resto de etapas y produce un informe completo; lo único que se pierde es la consulta a lore.kernel.org. La instalación, desde una copia del repositorio, se resuelve con `cargo install --force --path .`. Hay tres límites que conviene tener presentes antes de sacar conclusiones sobre su alcance. El primero es que Boro no ha reemplazado a Sashiko ni compite con el proceso de revisión pública: cubre la fase anterior. El segundo es que la detección de roturas en módulos fuera del árbol es un plan declarado, no una función terminada. El tercero es que la integración de parte de su funcionalidad dentro de Sashiko es una propuesta que Righi puso sobre la mesa en el LPC, sin decisión tomada. ## Lo que el kernel gana y lo que arriesga con la IA dentro El kernel de Linux es un proyecto de 35 años construido sobre una idea incómoda: que el mejor filtro para un cambio de bajo nivel sigue siendo otro humano que entiende el subsistema. Meter modelos en ese circuito no elimina la revisión humana, y Boro lo refleja bien al mantener al validador como puerta y al desarrollador como quien decide. Lo que cambia es la cantidad de trabajo mecánico que desaparece antes de que alguien mire. La pregunta abierta no es si estas herramientas van a usarse, sino con qué criterio. Boro acaba de poner código, licencia y prompts sobre la mesa, y eso permite auditar qué le está pidiendo exactamente a un modelo cuando dice que un parche está bien. Es una diferencia sustancial frente a los servicios cerrados que hacen lo mismo sin mostrar el criterio.