Linux lleva años permitiendo aplicar determinados parches de seguridad al kernel sin apagar una máquina, pero cambiar el kernel completo por una versión diferente manteniendo vivas cargas como máquinas virtuales, bases de datos o servicios en memoria es otro problema mucho más complejo. Dos tecnologías desarrolladas en buena medida alrededor de las necesidades de Google, Kexec HandOver (KHO) y Live Update Orchestrator (LUO), están acercando esa posibilidad al kernel estándar y podrían cambiar cómo se mantiene la infraestructura Linux de alta disponibilidad.
Las claves de KHO y LUO en 20 segundos
- KHO llegó al kernel Linux 6.16 y permite conservar regiones de memoria durante una transición mediante
kexec. - LUO se incorporó posteriormente en Linux 6.19 y organiza la conservación y recuperación de recursos entre ambos kernels.
- Su principal caso de uso son hipervisores cloud donde reiniciar el host afectaría a máquinas virtuales.
- systemd 261 ya integra LUO para conservar descriptores de fichero de servicios.
- Sigue siendo tecnología en desarrollo: cambiar de kernel sin reinicio convencional no significa todavía que cualquier servidor pueda actualizarse de forma transparente.
La distinción es importante porque LUO no es simplemente otro sistema de live patching. Ksplice, kpatch o KernelCare permiten modificar código de un kernel que continúa ejecutándose. Son muy útiles para corregir vulnerabilidades concretas sin reiniciar, pero el kernel sigue siendo esencialmente el mismo.
KHO y LUO plantean una operación diferente: arrancar realmente otro kernel mediante kexec, pero intentar trasladarle parte del estado que necesita la carga de trabajo.
La documentación del kernel describe Live Update como un proceso especializado de reinicio basado en kexec capaz de pasar de una versión del kernel a otra conservando determinados recursos y manteniendo operativos dispositivos compatibles durante la transición. El caso que ha empujado su desarrollo es precisamente el uso de Linux como hipervisor en grandes entornos cloud.
KHO es el puente de memoria entre dos kernels
kexec no es una tecnología nueva. Linux lleva años pudiendo cargar un nuevo kernel desde el kernel que ya está funcionando, evitando parte del proceso que se produce durante un arranque convencional y sin tener que atravesar de nuevo todo el firmware de la máquina.
El problema está en el estado.
Un nuevo kernel normalmente empieza desde una situación nueva. La memoria y determinados recursos que pertenecían al anterior no pueden darse simplemente por válidos.
Kexec HandOver (KHO) introduce precisamente una infraestructura para conservar regiones concretas de memoria durante ese salto.
KHO fue integrado en Linux 6.16 en 2025. La documentación del kernel lo define como un mecanismo capaz de preservar regiones de memoria, que pueden contener estados serializados del sistema, a través de una ejecución con kexec.
Su funcionamiento gira alrededor de una estructura denominada Flattened Device Tree (FDT). El kernel antiguo describe qué regiones deben conservarse y esa información acompaña a la transición. El nuevo kernel puede encontrar posteriormente esos bloques y reconstruir el estado que corresponda.
Simplificando mucho, el flujo se parece a esto:
Kernel Linux A
│
├── Estado que puede descartarse
│
└── Memoria que debe conservarse
│
▼
KHO
│
kexec
│
▼
Kernel Linux B
│
└── Recupera las regiones preservadasLa documentación actual exige que el kernel haya sido compilado con:
CONFIG_KEXEC_HANDOVER=yy que KHO se habilite durante el arranque con:
kho=onTambién pueden reservarse zonas de memoria auxiliares mediante kho_scratch. Un ejemplo documentado por el kernel es:
kho_scratch=16M,512M,256Mque reserva áreas específicas que permanecen disponibles para las operaciones necesarias durante futuros kexec.
Después el nuevo kernel se carga utilizando el cargador kexec_file del propio kernel:
kexec -l /ruta/al/bzImage --initrd /ruta/al/initrd -sy se realiza el salto:
kexec -eLa opción -s importa: la documentación indica que las herramientas de espacio de usuario no disponen actualmente de soporte KHO equivalente con el cargador tradicional.
Pero KHO por sí solo no resuelve todo el problema.
Puede entregar memoria al siguiente kernel. Falta saber qué representa esa memoria, qué procesos la utilizan y cómo reconstruir los recursos que dependen de ella.
Ahí aparece LUO.
LUO intenta mantener viva la carga mientras cambia el kernel
Live Update Orchestrator fue integrado en el kernel principal en Linux 6.19, después de construirse sobre las bases que había proporcionado KHO.
Su objetivo es coordinar todo el proceso de preservación.
LUO dispone de sesiones que agrupan recursos que deben sobrevivir a la transición. Un agente en espacio de usuario crea una sesión, incorpora los recursos que deben preservarse y, cuando llega el kexec, el kernel serializa la información necesaria.
Después del arranque del nuevo kernel, esa misma sesión puede recuperarse por nombre.
El ciclo básico es:
1. Crear sesión LUO
2. Registrar recursos
3. Preservar estado
4. Congelar los elementos necesarios
5. Ejecutar kexec
6. Arrancar el nuevo kernel
7. Recuperar la sesión
8. Reconstruir los recursos
9. Continuar la carga de trabajoLa interfaz se encuentra normalmente en:
/dev/liveupdatey está controlada mediante llamadas ioctl. Además, solo un proceso puede mantener abierto /dev/liveupdate al mismo tiempo para evitar que dos orquestadores intenten dirigir una actualización simultáneamente.
Para habilitar LUO el kernel debe arrancar con:
liveupdate=onLa documentación actual contempla explícitamente subsistemas como KVM, IOMMU, interrupciones, VFIO, memoria y determinados sistemas de archivos como posibles participantes en el proceso.
Esto empieza a explicar por qué Google tiene tanto interés en el proyecto.
El caso difícil: actualizar el host sin apagar sus máquinas virtuales
Supóngase un servidor físico con decenas de máquinas virtuales.
Aparece una vulnerabilidad del kernel que requiere instalar una versión nueva.
El procedimiento tradicional sería migrar las máquinas a otros nodos o apagarlas, actualizar el host y reiniciarlo.
En grandes nubes esas operaciones tienen un coste considerable.
No solamente en interrupciones visibles. También en capacidad adicional necesaria para recibir las máquinas migradas, tráfico de red, tiempo operativo y coordinación de miles de hosts.
LUO persigue otro escenario.
Una máquina virtual gestionada por QEMU/KVM mantiene buena parte de su estado en memoria y utiliza recursos del kernel como memfd, VFIO o IOMMU.
Si esos elementos pueden conservarse durante el kexec, el host podría:
Kernel antiguo
│
├── QEMU
│ └── VM en ejecución
│
▼
Preservar memoria y recursos
│
▼
kexec
│
▼
Kernel nuevo
│
├── Recuperar recursos
│
└── Volver a asociarlos a la VMLa documentación de LUO señala expresamente como objetivo permitir que cargas como máquinas virtuales que utilizan vfio, memfd o iommufd conserven sus recursos esenciales durante la transición. Incluso determinados dispositivos pueden continuar con actividad DMA mientras cambia el kernel.
Desde el punto de vista del usuario de la máquina virtual, la aspiración es que el cambio del kernel del hipervisor tenga una interrupción mínima o resulte prácticamente imperceptible.
Eso es bastante diferente de aplicar un parche sobre unas pocas funciones.
El servidor ha terminado ejecutando otro kernel.
Google ha publicado también luo-agent para controlar el proceso
El kernel proporciona la infraestructura, pero alguien tiene que coordinarla desde espacio de usuario.
Google mantiene el proyecto abierto googleprodkernel/luo-agent, escrito principalmente en C y publicado bajo GPL-2.0.
El proyecto contiene dos componentes principales:
luodes el daemon que controla /dev/liveupdate.
Y:
luoctles la herramienta administrativa utilizada para cargar kernels, consultar sesiones y lanzar la transición.
La arquitectura busca evitar que cada aplicación tenga que controlar directamente todo el procedimiento.
luod mantiene la sesión y los clientes, por ejemplo un proceso QEMU, se suscriben a través de un socket Unix.
El flujo previsto es aproximadamente:
Administrador
│
luoctl
│
▼
luod
│
├── Cliente QEMU
├── Base de datos
└── Otro servicio compatible
│
▼
sesiones LUO
│
▼
KernelSegún la documentación del proyecto, los clientes se conectan a:
/run/luod/liveupdate.socky pueden recibir descriptores de sesión mediante SCM_RIGHTS, el mecanismo Unix que permite transferir file descriptors entre procesos.
Antes del salto el cliente recibe una solicitud de preservación, guarda sus recursos y responde que está preparado.
Después de kexec, vuelve a conectarse utilizando el mismo identificador y reclama su sesión.
El planteamiento resulta especialmente interesante porque evita imponer un formato único de estado para todas las aplicaciones. Cada cliente conoce mejor que el orquestador qué recursos necesita mantener.
La actualización ya puede conservar file descriptors con systemd 261
LUO tampoco está limitado al agente experimental de Google.
La documentación actual del kernel señala que systemd, desde la versión 261, integra soporte para LUO y puede conservar su almacén de descriptores de fichero por servicio durante una actualización basada en kexec.
Los servicios pueden utilizar las opciones:
FileDescriptorStoreMax=y:
FileDescriptorStorePreserve=para indicar qué descriptores mantiene systemd.
Esto importa porque los file descriptors son mucho más que números.
Pueden representar:
- archivos abiertos;
- pipes;
- determinados sockets;
- memoria mediante
memfd; - recursos proporcionados por dispositivos;
- sesiones LUO.
Conservarlos permite que un servicio nuevo, ejecutado después de la transición, recupere recursos que pertenecían al proceso anterior.
El kernel pone como ejemplo una aplicación de caché en memoria como memcached: sus gigabytes de datos podrían residir en un memfd, conservarse durante el cambio y recuperarse sin reconstruir toda la caché desde almacenamiento.
Esto amplía bastante el interés de LUO más allá de los hipervisores.
Bases de datos, contenedores y networking podrían ser los siguientes
La propia documentación deja claro que el diseño pretende ser independiente de la carga de trabajo.
Habla explícitamente de:
- máquinas virtuales;
- contenedores;
- bases de datos de alto rendimiento;
- servicios de red;
- caches en memoria.
Pero existe una diferencia importante entre que el framework pueda soportarlos y que cualquier aplicación actual sobreviva ya automáticamente a un cambio de kernel.
LUO necesita controladores capaces de preservar los distintos tipos de recursos.
Por eso su arquitectura incluye operaciones como:
can_preserve()
preserve()
freeze()
retrieve()
finish()El kernel antiguo tiene que saber cómo serializar el estado y el nuevo cómo reconstruirlo.
Es una infraestructura extensible, no una máquina del tiempo universal para cualquier proceso Linux.
En ese sentido puede complementarse con otra tecnología conocida: CRIU (Checkpoint/Restore in Userspace).
CRIU permite capturar el estado de procesos y restaurarlos posteriormente. Se utiliza, entre otras cosas, para migración y checkpoint de contenedores.
KHO, LUO y CRIU operan en capas diferentes, pero su combinación permite imaginar escenarios donde una parte del estado permanezca físicamente en RAM mientras otra se serializa y reconstruye desde espacio de usuario.
Todavía queda trabajo antes de que algo así sea transparente para cualquier aplicación.
No es exactamente una actualización «sin reinicio»
Aquí conviene introducir un matiz importante.
Decir que LUO permite cambiar el kernel «sin reiniciar» resulta comprensible como resumen, pero técnicamente puede inducir a error.
Sí existe un reinicio del kernel.
LUO utiliza kexec.
El kernel antiguo deja de ejecutarse y se inicia uno nuevo.
Lo que se pretende eliminar es el reinicio completo tradicional de la máquina y, sobre todo, la interrupción de las cargas que dependen de ella.
No se pasa por todo el ciclo habitual:
apagar
BIOS/UEFI
firmware
bootloader
kernel
servicios
aplicacionesEn su lugar:
kernel antiguo
│
kexec
│
kernel nuevoy KHO/LUO intentan transportar suficiente estado entre ambos.
Esta precisión es importante porque también marca los límites de la tecnología.
Un cambio de firmware, determinadas modificaciones de hardware o problemas que requieren reinicializar físicamente un dispositivo seguirán necesitando otro tipo de mantenimiento.
LUO tampoco sustituye al live patching
Kpatch, Ksplice y tecnologías similares continúan teniendo sentido.
Las dos estrategias resuelven necesidades diferentes.
El live patching sería:
Kernel 6.x
│
aplicar parche
│
Kernel 6.x modificadoLUO plantea:
Kernel A
│
preservar estado
│
kexec
│
Kernel BPara una vulnerabilidad pequeña, cambiar algunas funciones mediante un parche puede ser bastante menos arriesgado que sustituir todo el kernel.
Pero el live patching acumula limitaciones.
No cualquier modificación puede convertirse cómodamente en un parche en vivo. Y a medida que pasan las semanas pueden acumularse diferencias entre el kernel originalmente arrancado y su versión parcheada.
Una transición completa ofrece la posibilidad de ejecutar realmente el kernel que contiene todas las correcciones integradas.
Por eso ambas tecnologías pueden terminar conviviendo: live patching para ganar tiempo y LUO para realizar posteriormente una actualización completa con una interrupción mucho menor.
Todavía no debería activarse a ciegas en producción
Aunque la tecnología ya está dentro del kernel principal, continúa siendo joven.
La documentación oficial de la API de Live Update advierte explícitamente de que sigue en desarrollo y todavía no se garantiza la compatibilidad al realizar transiciones entre diferentes versiones de kernel. Esa estabilidad está prevista para una fase posterior.
KHO conserva además interfaces de depuración que la propia documentación avisa que pueden cambiar a medida que el subsistema se estabiliza.
Por tanto, encontrar CONFIG_KEXEC_HANDOVER o soporte LUO en una distribución no convierte automáticamente este mecanismo en una función lista para cualquier servidor crítico.
El repositorio actual de luo-agent, por ejemplo, establece como requisito un kernel 6.19 o posterior con CONFIG_LIVEUPDATE habilitado.
Una configuración de arranque destinada a pruebas puede incorporar:
kho=on
kho_scratch=16M,512M,256M
liveupdate=onpero eso solo habilita las piezas del kernel.
La carga que se quiere preservar también necesita soporte.
Por qué esta tecnología importa ahora más que hace diez años
El problema de los reinicios de kernel no es nuevo.
Lo que ha cambiado es el tamaño de la infraestructura que depende de Linux.
Un proveedor cloud puede tener miles de hipervisores físicos. Un solo host puede ejecutar decenas o cientos de máquinas virtuales.
Cuando aparece una vulnerabilidad grave, actualizar no consiste simplemente en programar un reinicio nocturno.
Hay que:
- desalojar máquinas virtuales;
- migrarlas a otros hosts;
- mantener capacidad libre suficiente;
- coordinar actualizaciones;
- vigilar errores;
- devolver posteriormente las cargas.
En centros de datos con GPU la operación puede ser todavía más complicada por el precio de los recursos y las características de dispositivos que utilizan passthrough o VFIO.
Además, el descubrimiento automatizado de vulnerabilidades está aumentando la velocidad con la que se encuentran nuevos fallos en software complejo. La IA es una de las herramientas que están acelerando esta búsqueda, aunque sería excesivo atribuir a ella por sí sola el volumen actual de vulnerabilidades del kernel.
Cuanto menor sea el coste operativo de cambiar rápidamente a un kernel corregido, menor será la presión para posponer actualizaciones.
Ahí está probablemente la relevancia real de KHO y LUO.
No se trata de presumir de que Linux nunca necesita reiniciarse.
Se trata de intentar separar dos cosas que históricamente estaban unidas:
actualizar el sistema operativo del host y detener la carga que está ejecutando.
Si esa separación termina funcionando de forma estable con máquinas virtuales, dispositivos, contenedores, redes y bases de datos, una actualización del kernel podría acabar pareciéndose mucho más a una operación ordinaria de mantenimiento.
Todavía no se ha llegado a ese punto.
Pero desde Linux 6.16 con KHO, Linux 6.19 con LUO y systemd 261 con integración de descriptores de fichero, las piezas fundamentales ya no son únicamente experimentos publicados en una lista de correo. Están empezando a formar parte de la infraestructura estándar de Linux.
Preguntas frecuentes
¿Puede Linux actualizar ya cualquier kernel sin reiniciar el servidor?
No de forma transparente para cualquier sistema. KHO y LUO permiten realizar una transición mediante kexec conservando determinados estados y recursos, pero necesitan soporte del kernel, del espacio de usuario y de las aplicaciones implicadas.
¿Cuál es la diferencia entre LUO y Kpatch o Ksplice?
Kpatch y Ksplice modifican en caliente un kernel que continúa ejecutándose. LUO permite arrancar un kernel diferente mediante kexec e intenta conservar los recursos necesarios para mantener la carga de trabajo.
¿Qué versiones de Linux incorporan KHO y LUO?
La infraestructura inicial de Kexec HandOver llegó en Linux 6.16, mientras que Live Update Orchestrator se integró en Linux 6.19. systemd añadió integración con LUO en su versión 261.
¿Para qué sirve luo-agent de Google?
luo-agent proporciona los componentes de espacio de usuario que coordinan LUO. Incluye el daemon luod y la herramienta luoctl, que permiten cargar un nuevo kernel, gestionar sesiones y lanzar la transición mediante kexec.
Fuentes:
- Linux Kernel Documentation, Kexec HandOver (KHO).
- Linux Kernel Documentation, Live Update Orchestrator y Live Update uAPI.
- Google Production Kernel, proyecto abierto
luo-agenten GitHub. - systemd 261, integración del File Descriptor Store con Live Update.
- Phoronix, seguimiento de la integración de KHO en Linux 6.16 y LUO en Linux 6.19.
