Parcheo en vivo del kernel frente a reiniciar el VPS

Qué hace el parcheo en vivo del kernel en un VPS

El parcheo en vivo del kernel aplica correcciones de seguridad del kernel en una máquina en ejecución, sin reiniciarla ni interrumpir las conexiones. Se carga una copia corregida de una función como módulo del kernel y cada llamada a la función antigua se redirige a la nueva copia mientras el servidor sigue atendiendo tráfico. Este mecanismo explica tanto para qué sirve el parcheo en vivo como qué limitaciones tiene.

Gana tiempo. No elimina la necesidad de reiniciar. Un servidor al que se ha aplicado parcheo en vivo durante seis meses sigue arrancando con la imagen antigua del kernel almacenada en disco, y todos esos parches sólo existen en la memoria.

El parcheo en vivo suele ofrecerse como una función de un plan gestionado. En un servidor no gestionado puede activarlo usted mismo con dos comandos. Conviene saberlo antes de pagar la diferencia entre un VPS gestionado y uno no gestionado.

¿Cómo funciona el parcheo en vivo del kernel?

El kernel incluye un núcleo integrado de parcheo en vivo, compilado con CONFIG_LIVEPATCH. Compruébelo en el kernel en ejecución:

grep CONFIG_LIVEPATCH /boot/config-$(uname -r)

Una línea con CONFIG_LIVEPATCH=y indica que el kernel en ejecución se compiló con el núcleo presente. Sin él, ningún servicio de parcheo en vivo puede hacer nada en ese equipo.

La redirección utiliza ftrace, el trazador de funciones del kernel. La mayoría de las funciones del kernel se compilan con una instrucción de llamada al principio de la función, antes de que se modifiquen los argumentos o la pila. Ftrace utiliza ese punto de llamada como enlace. Al aplicar un parche, el núcleo de parcheo en vivo registra un controlador de ftrace en la función objetivo, y el controlador redirige la ejecución a la función de reemplazo. La documentación del kernel lo explica de forma directa: "El parcheo en vivo normalmente debe redirigir el código al principio de la entrada de la función, antes de que los parámetros de la función o la pila se modifiquen de cualquier forma."

De esa frase se desprenden dos consecuencias, y ambas serán importantes más adelante. Sólo se puede parchear una función que ftrace pueda enlazar; por tanto, una función compilada sin esa llamada de entrada no se puede parchear. Además, la unidad de parcheo es una función completa, nunca una sola línea dentro de ella.

La parte más difícil es cambiar el código de forma segura en un sistema en ejecución. Si el código antiguo todavía se ejecuta en la pila de algún CPU cuando se cambia la función, se mezclan comportamientos antiguos y nuevos. Linux upstream gestiona esto con un modelo de coherencia por tarea, descrito en la documentación del kernel como un modelo híbrido: "utiliza la coherencia por tarea y el cambio mediante barrera de llamadas al sistema de kGraft, combinados con el cambio mediante trazas de pila de kpatch." Las tareas pasan al código nuevo una por una, sólo cuando el kernel puede demostrar que la tarea no está dentro de una función parcheada. Hasta que todas las tareas hayan cambiado, el parche está en transición.

Puede ver el resultado directamente. Los parches aplicados aparecen en /sys/kernel/livepatch, con un directorio por parche y las funciones parcheadas dentro.

ls /sys/kernel/livepatch/

Una lista vacía indica que no hay ningún parche en vivo cargado en memoria. En un servidor recién instalado, este es el estado inicial normal.

Qué no puede corregir el parcheo dinámico del kernel

Se parchean los cuerpos de las funciones. Todo lo demás queda sin cambios.

• Estructuras de datos modificadas. Si la corrección del proyecto upstream añade un campo a una estructura o cambia el significado de un campo existente, no hay una forma segura de reescribir los objetos que ya están asignados y en uso. El proyecto kpatch indica directamente el caso equivalente: "Patches which modify statically allocated data are not directly supported." Las variables shadow y las callbacks existen como solución alternativa, pero se escriben manualmente para cada parche y no son automáticas.
• Correcciones distribuidas entre varias funciones al mismo tiempo. Una corrección que cambia el orden de adquisición de bloqueos en un grupo de funciones necesita que todas cambien juntas, y el modelo de coherencia cambia las tareas en lugar de congelar toda la máquina en un único instante.
• Código de inicialización. Las funciones marcadas con __init ya se han ejecutado y liberado cuando el servidor está operativo, por lo que no queda nada que redirigir.
• Nuevas versiones del kernel y nuevas funciones. El parcheo dinámico permite avanzar dentro de un nivel de parches de una misma serie del kernel. Nunca permite pasar de una serie a la siguiente y nunca añade una función. Si necesita algo de una serie más reciente, como los cambios incorporados en Linux 7.1, instale ese kernel e inícielo.
• Espacio de usuario. Canonical establece claramente el límite: "Canonical Livepatch does not patch userspace libraries like OpenSSL or glibc, because that is the responsibility of unattended-upgrades or a systems management tool." Un kernel parcheado dinámicamente junto a un OpenSSL obsoleto no constituye un servidor parcheado, así que mantenga unattended upgrades gestionando los paquetes del espacio de usuario en el mismo equipo.

El servicio de Ubuntu también tiene un límite de gravedad. Canonical indica que "patches kernel vulnerabilities with critical and high Common Vulnerability Scoring System (CVSS) and Ubuntu Priority ratings." Un identificador CVE (common vulnerabilities and exposures) designa una vulnerabilidad, y CVSS es la puntuación asociada. Una vulnerabilidad CVE del kernel con gravedad media se corrige en el paquete almacenado en disco y no se parchea dinámicamente, por lo que llega al kernel en ejecución en el siguiente reinicio y no antes.

¿Qué opciones existen para aplicar parches al kernel en ejecución?

Hay tres líneas de desarrollo de uso habitual, y todas utilizan la misma infraestructura del kernel.

Canonical Livepatch se distribuye mediante Ubuntu Pro. Ubuntu Pro es gratuito para uso personal, y Canonical indica que «es y siempre será gratuito para uso personal en hasta 5 máquinas físicas», con un límite de 50 máquinas para los miembros oficiales de Ubuntu Community. Este es el límite documentado en agosto de 2026. El uso comercial requiere una suscripción de pago. La cobertura se concede por serie de kernel y por variante, e incluye los kernels de disponibilidad general (GA) de las versiones de soporte a largo plazo (LTS) compatibles y sus kernels de habilitación de hardware (HWE), en variantes como generic, aws, azure, gcp, oracle, ibm y lowlatency. Compruebe su propio kernel en la lista de kernels publicada por Canonical antes de depender de esta opción.

KernelCare, de TuxCare, es un agente comercial compatible con muchas distribuciones, incluidas algunas que no tienen un servicio propio. Su instalación documentada utiliza un script del proveedor, curl -s -L https://kernelcare.com/installer | bash, seguido de /usr/bin/kcarectl --register KEY para una licencia basada en una clave. Después, el agente busca nuevos parches según su propia programación, y /usr/bin/kcarectl --update fuerza una comprobación. Lea el instalador antes de canalizarlo a un shell en un servidor importante.

kpatch y kGraft son los proyectos precursores. kGraft procedía de SUSE y kpatch de Red Hat. El núcleo de aplicación de parches en ejecución del Linux upstream actual combina ambas ideas. kpatch está dejando de desarrollarse: su README indica que, a partir de Linux 6.19, «el proyecto kpatch está obsoleto y en modo de mantenimiento», y que kpatch-build se sustituirá por klp-build en el kernel upstream. En RHEL y sus reconstrucciones, debe utilizar el servicio propio de la distribución en lugar de crear parches manualmente.

Elija según lo que admita su distribución y lo que permita su licencia. El resultado a nivel del kernel es el mismo en todos los casos.

Cómo habilitar Canonical Livepatch en Ubuntu

Primero obtenga un token en la página de su cuenta de Ubuntu Pro. Los dos comandos siguientes necesitan acceso de red saliente operativo, porque el cliente se comunica con los servidores de Canonical para asociar el sistema y descargar parches.

sudo pro attach TOKEN
sudo pro status

Ejecutar sudo pro attach sin un token inicia un flujo basado en el navegador y muestra un código que debe introducir en el sitio de Canonical. La asociación habilita automáticamente los servicios recomendados, entre los que se incluye Livepatch en una versión LTS actual. Use sudo pro attach --no-auto-enable si prefiere seleccionar los servicios manualmente.

Si Livepatch todavía no está habilitado:

sudo pro enable livepatch
sudo canonical-livepatch status

El servicio se ejecuta desde el snap canonical-livepatch, por lo que snapd debe funcionar correctamente para que finalice el proceso de habilitación. pro status muestra una tabla de servicios con su derecho de uso y estado. canonical-livepatch status muestra los detalles por kernel, y la documentación de Canonical presenta la salida con este formato:

last check: 52 seconds ago
kernel: 5.4.0-216.236-generic
server check-in: succeeded
kernel state: ✓ kernel series 5.4 is covered by Livepatch
patch state: ✓ all applicable livepatch kernel modules applied
patch version: 113.1

Dos líneas contienen la respuesta. kernel state indica si la serie que está ejecutando está cubierta por el servicio y es la línea que cambia a un estado incorrecto cuando se inicia un kernel que Livepatch no admite. patch state indica si los parches aplicables a ese kernel se han cargado realmente. Un kernel cubierto sin parches aplicados indica un problema del cliente. Un kernel no cubierto indica un problema del kernel, y ningún ajuste del cliente puede solucionarlo.

¿Cómo saber si hay un reinicio pendiente?

Livepatch elimina la urgencia, por lo que un reinicio pendiente deja de ser evidente. Hay que buscarlo.

ls -l /var/run/reboot-required
cat /var/run/reboot-required.pkgs

El gestor de paquetes crea /var/run/reboot-required cuando un paquete instalado necesita un reinicio para aplicar los cambios, y un paquete nuevo linux-image siempre lo crea. El archivo .pkgs indica qué paquetes lo solicitaron. Si el primer comando devuelve No such file or directory, ningún paquete ha solicitado un reinicio desde el último arranque de la máquina. En las versiones actuales de Ubuntu, /var/run es un enlace simbólico a /run, por lo que ambas rutas llevan al mismo archivo.

Ese indicador reside en un tmpfs y se restablece en cada arranque. Por eso, hay que comprobarlo también directamente en el kernel:

uname -r
dpkg -l 'linux-image-*' | grep ^ii

uname -r muestra el kernel en ejecución. El segundo comando muestra los paquetes del kernel instalados en el disco. Si en esa lista aparece un linux-image más reciente que el que indica uname -r, la máquina está ejecutando un kernel antiguo, independientemente del estado de Livepatch. Esta es la comprobación importante, porque live patching está diseñado para mantener seguro el kernel en ejecución, no para mantenerlo actualizado.

Para la parte de userspace de la misma comprobación, needrestart viene instalado de forma predeterminada en Ubuntu Server y muestra los servicios en ejecución que todavía mantienen abiertos archivos de biblioteca eliminados.

sudo needrestart -r l

El par de opciones -r l significa «mostrar únicamente», por lo que sólo informa y no cambia nada.

Por qué el reinicio sigue siendo necesario

El kernel del disco no cambia. Los parches en vivo se cargan en el kernel en ejecución y nunca se escriben en la imagen de arranque. Por eso, un reinicio inicia el sistema con el linux-image que seleccione el gestor de arranque, y el cliente de Livepatch vuelve a aplicar los parches que todavía sean aplicables. Durante esos dos momentos se ejecuta código sin parches. Esta es otra razón para arrancar con un kernel actual en lugar de uno antiguo.

La cobertura se define por serie de kernel, y las series se retiran. Cuando la serie en ejecución deja de estar en la lista de versiones compatibles, la línea kernel state deja de informar sobre la cobertura. La única solución es usar un kernel más reciente. Eso requiere un reinicio. En una versión LTS, la nueva serie suele llegar como un kernel de habilitación de hardware incluido en una actualización puntual como 26.04.1, por lo que el reemplazo ya está disponible en el archivo de paquetes. Sólo falta realizar un arranque programado.

Las correcciones del kernel de gravedad media y baja nunca se aplican en vivo. Permanecen en el paquete del disco y sólo estarán disponibles después de arrancar con ese kernel.

Los kernels que permanecen en ejecución durante mucho tiempo también acumulan estado que los parches no limpian. Conviene citar la posición de Canonical, porque es clara: Livepatch "no sustituye al reinicio. Es una herramienta que permite controlar mejor el momento del reinicio al evitar los reinicios no programados". La palabra clave es no programados. El sistema sigue necesitando reinicios. Usted decide cuándo realizarlos.

Cómo programar un reinicio que permita recuperar el acceso

Un reinicio de un VPS es irreversible si no puede acceder a la consola. Antes de ejecutar reboot, asegúrese de poder volver a entrar si la máquina no vuelve a estar disponible.

• Confirme que su proveedor ofrece una consola serie o una vista VNC (virtual network computing) en el panel de control, y ábrala ahora en lugar de esperar a una interrupción.
• Compruebe el espacio disponible con df -h /boot. Si /boot está lleno, el paquete del kernel falla al escribir su initramfs (initial RAM filesystem). Esto puede dejar una entrada del cargador de arranque que apunta a una imagen que nunca terminó de escribirse.
• Mantenga instalado al menos un kernel anterior que sepa que funciona. GRUB lo muestra en "Advanced options for Ubuntu", y arrancar con él es la forma más rápida de recuperar el sistema cuando falla un kernel nuevo.
• Localice el modo de rescate de su proveedor antes de necesitarlo. Si la consola muestra un indicador de initramfs después del reinicio, la reparación se realiza desde ahí.

Después, reinicie en un momento en el que esté disponible:

sudo shutdown -r +5 "Kernel update, back in a moment"

Esto programa el reinicio para dentro de cinco minutos y envía un mensaje a los usuarios conectados. sudo shutdown -c lo cancela. Cuando la máquina vuelva a estar disponible, confirme ambos aspectos:

uname -r
sudo canonical-livepatch status

uname -r debería informar ahora del kernel más reciente, y la salida de estado debería indicar que la nueva serie está cubierta. Si la máquina no vuelve a estar disponible, el fallo casi siempre está en la ruta de arranque y no en la red. En ese caso, siga el procedimiento de la guía para un VPS que no arranca después de actualizar el kernel.

Por qué es necesario seguir limpiando los kernels antiguos

El live patching empeora este problema en lugar de resolverlo, porque elimina la necesidad de reiniciar mientras se siguen instalando paquetes linux-image. Cada kernel instala una imagen de arranque, un initramfs, un árbol de módulos y, normalmente, un paquete de headers. En un VPS pequeño con una partición /boot independiente de unos cientos de megabytes, tres o cuatro kernels pueden llenarla.

Un /boot lleno impide instalar el siguiente kernel. Así, la máquina puede quedar sin capacidad para aplicar precisamente la actualización que necesita. La ruta de apt autoremove elimina los kernels antiguos cuando cumplen los requisitos, pero en un equipo que nunca se reinicia todavía no siempre cumplen esos requisitos, porque el gestor de paquetes no retirará un kernel que todavía podría estar en ejecución.

Por tanto, compruebe qué está instalado, conserve el kernel en ejecución y una alternativa conocida y fiable, y elimine el resto mediante el procedimiento seguro para eliminar kernels antiguos en Ubuntu. Nunca elimine el kernel que uname -r indique que está en ejecución.

FAQ

¿El parcheo dinámico del kernel significa que nunca tengo que reiniciar mi VPS?

No. Los parches dinámicos se cargan en el kernel en ejecución y no se escriben en la imagen de arranque, por lo que el linux-image del disco mantiene la versión con la que se inició el sistema. Canonical lo indica directamente: Livepatch «no sustituye al reinicio. Es una herramienta que proporciona más control al evitar reinicios no programados». La cobertura también termina cuando la serie del kernel deja de recibir soporte, y las correcciones de gravedad media del kernel nunca se aplican mediante parches dinámicos. Programe los reinicios de mantenimiento con la periodicidad que elija, en lugar de esperar a que sea necesario forzarlos.

¿Cómo compruebo si el parcheo dinámico del kernel está aplicando parches realmente?

Ejecute sudo canonical-livepatch status y revise dos líneas. kernel state indica si la serie del kernel en ejecución está cubierta por el servicio, y patch state indica si los parches para ese kernel están cargados. También puede comprobar directamente el estado del kernel con ls /sys/kernel/livepatch/, que muestra un directorio por cada parche cargado. Una lista vacía significa que no hay ningún parche aplicado en memoria en ese momento, independientemente de lo que indique el cliente.

¿Ubuntu Pro es gratuito en un VPS personal?

Sí, dentro de un límite documentado. Canonical indica que Ubuntu Pro «es y siempre será gratuito para uso personal en hasta 5 máquinas físicas», con un límite de 50 máquinas para los miembros oficiales de Ubuntu Community, a fecha de agosto de 2026. El uso comercial requiere una suscripción de pago. Asocie una máquina con sudo pro attach TOKEN mediante un token de la página de su cuenta de Ubuntu Pro y, después, habilite el servicio con sudo pro enable livepatch.

¿Por qué un CVE del kernel sigue apareciendo como no corregido después de ejecutar Livepatch?

Normalmente, por uno de dos motivos. La corrección puede estar por debajo del umbral de gravedad, porque Canonical aplica parches dinámicos a «vulnerabilidades del kernel con calificaciones críticas y altas según el Common Vulnerability Scoring System (CVSS) y las prioridades de Ubuntu», y deja el resto en manos del paquete instalado en el disco. O puede que la corrección no se pueda expresar como un cambio en el cuerpo de una función, por ejemplo, cuando el proyecto original modificó una estructura de datos. El parcheo dinámico no puede hacer esto de forma segura en objetos que ya se han asignado. Ambos casos se resuelven de la misma forma: instale el paquete actualizado del kernel e inicie el sistema con él.

¿Qué no cubre en absoluto el parcheo dinámico del kernel?

El espacio de usuario. Canonical especifica que Livepatch «no aplica parches a bibliotecas del espacio de usuario como OpenSSL o glibc, porque esa responsabilidad corresponde a unattended-upgrades o a una herramienta de gestión de sistemas». Tampoco puede proporcionar una nueva versión del kernel ni una función nueva, ya que sólo reemplaza cuerpos de funciones dentro de la serie que ya está ejecutando. Además, no puede aplicar parches a funciones __init, que ya se han ejecutado y se han liberado de la memoria cuando el servidor está activo.