Parcheo en vivo del kernel o reinicio del VPS

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

El parcheo en vivo aplica correcciones de seguridad del kernel en una máquina en ejecución, sin reiniciar 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é no puede hacer.

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 cada uno de esos parches sólo existe en memoria.

El parcheo en vivo suele ofrecerse como una característica de un plan administrado. En un servidor no administrado puede habilitarlo usted mismo con dos comandos. Conviene saberlo antes de pagar la diferencia entre un VPS administrado y uno no administrado.

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

El kernel incluye un núcleo integrado de parcheo en vivo, compilado con CONFIG_LIVEPATCH. Compruebe si el kernel en ejecución lo tiene:

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

Una línea que muestre CONFIG_LIVEPATCH=y significa 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 usa ftrace, el rastreador 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 usa ese punto de llamada como enlace. Cuando se aplica un parche, el núcleo de parcheo en vivo registra un controlador de ftrace para la función de destino y el controlador envía la ejecución a la función de reemplazo. La documentación del kernel lo explica claramente: «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 son 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 un sistema en ejecución de forma segura. Si el código antiguo todavía se está ejecutando en la pila de alguna CPU cuando se cambia la función, se obtiene una combinación de 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: «usa la coherencia por tarea y el cambio mediante barrera de llamadas al sistema de kGraft, combinados con el cambio de 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á actualmente 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 significa que no hay ningún parcheo 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 original 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 funciones de callback existen como solución alternativa, pero deben escribirse manualmente para cada parche; no se generan de forma automática.
• Correcciones distribuidas entre varias funciones a la vez. Una corrección que cambia el orden de los 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 ya no queda nada que redirigir.
• Nuevas versiones del kernel y nuevas funciones. El parcheo dinámico permite avanzar dentro de un nivel de parche de una misma serie del kernel. Nunca permite pasar de una serie a la siguiente ni añade funciones. Si necesita algo de una serie más reciente, como los cambios incorporados en Linux 7.1, debe instalar ese kernel e iniciarlo.
• Espacio de usuario. Canonical establece claramente este 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 con parches dinámicos junto a un OpenSSL obsoleto no es un servidor corregido. Por tanto, 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 un fallo, y CVSS es la puntuación asociada. Una CVE del kernel con nivel de gravedad medio se corrige en el paquete almacenado en disco y no mediante un parche dinámico. Por tanto, llega al kernel en ejecución en el siguiente reinicio, y no antes.

¿Cuáles son las opciones para aplicar parches al kernel en ejecución?

Hay tres líneas principales de uso habitual. Todas utilizan los mismos mecanismos del kernel.

Canonical Livepatch se distribuye mediante Ubuntu Pro. Ubuntu Pro es gratuito para uso personal. Canonical indica que «es y siempre será gratuito para uso personal en un máximo de 5 máquinas físicas». El límite aumenta a 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. Incluye los kernels de disponibilidad general (GA) de las versiones de soporte extendido 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 clave. Después, el agente comprueba si hay parches nuevos según su propia programación. /usr/bin/kcarectl --update fuerza una comprobación. Lea el instalador antes de enviarlo 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 de Linux upstream combina actualmente ambas ideas. kpatch está desapareciendo. Su README indica que, a partir de Linux 6.19, «el proyecto kpatch está obsoleto y en modo de mantenimiento». kpatch-build se sustituye por klp-build en el kernel upstream. En RHEL y sus reconstrucciones, debe utilizar el servicio propio de la distribución en lugar de compilar los 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, incluido 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 para que el proceso de habilitación termine correctamente. 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. Esta línea cambia a un estado incorrecto cuando se inicia un kernel que Livepatch no admite. patch state indica si los parches aplicables a ese kernel están realmente cargados. Un kernel cubierto sin parches aplicados indica un problema del cliente. Un kernel no cubierto indica un problema del kernel, y ninguna configuración del cliente lo corrige.

¿Cómo puedo saber si hay un reinicio pendiente?

Livepatching elimina la emergencia, por lo que un reinicio pendiente deja de ser evidente. Debe 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 contiene la lista de paquetes que 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 se encuentra en un tmpfs y se restablece en cada arranque, por lo que debe comprobarlo también en el propio 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 del espacio de usuario de esta misma comprobación, needrestart se instala de forma predeterminada en Ubuntu Server y muestra los servicios en ejecución que todavía mantienen abiertos archivos de bibliotecas eliminados.

sudo needrestart -r l

El par de indicadores -r l significa «mostrar solamente», por lo que sólo informa y no modifica nada.

Por qué el reinicio nunca desaparece

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 el gestor de arranque seleccione, y el cliente de Livepatch vuelve a aplicar los parches que siguen siendo aplicables. Durante esos dos momentos, el sistema ejecuta código sin parches. Esta es otra razón para iniciar con un kernel actual y no con uno antiguo.

La cobertura se aplica por serie de kernels, y las series dejan de recibir soporte. Cuando la serie en ejecución deja de estar en la lista de series compatibles, la línea de kernel state deja de informar sobre la cobertura. La única solución es usar un kernel más reciente. Eso requiere un reinicio.

Las correcciones del kernel de gravedad media y baja nunca se aplican mediante parches en vivo. Permanecen en el paquete almacenado en el disco y sólo se aplican cuando se inicia el sistema 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 postura de Canonical, porque es la más clara: Livepatch «no sustituye al reinicio. Es una herramienta que permite controlar mejor el momento, al evitar reinicios no programados». La palabra importante es no programados. Aun así, debe reiniciar. Usted elige cuándo.

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 acceder cuando la máquina no se recupere.

• Confirme que su proveedor ofrece una consola serie o una vista VNC (computación de red virtual) en el panel de control, y ábrala ahora en lugar de esperar a una interrupción.
• Compruebe el espacio libre con df -h /boot. Un /boot lleno hace que el paquete del kernel falle al escribir su initramfs (sistema de archivos raíz inicial), lo que puede dejar una entrada del gestor de arranque que apunta a una imagen incompleta.
• Mantenga instalado al menos un kernel antiguo que sepa que funciona. GRUB lo muestra en "Advanced options for Ubuntu", y arrancarlo es la forma más rápida de recuperarse 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, ahí es donde debe realizar la reparación.

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

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 del 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 eliminar los kernels antiguos

El live patching empeora este problema en lugar de resolverlo, porque elimina la necesidad de reiniciar mientras se siguen instalando paquetes de 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 la llenan.

Una partición /boot llena interrumpe la siguiente instalación del kernel. Así, una máquina puede quedar sin capacidad para aplicar precisamente la actualización que necesita. La ruta 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 aún podría estar en ejecución.

Por tanto, compruebe qué está instalado, conserve el kernel en ejecución y un kernel de respaldo conocido como estable, y elimine el resto mediante el procedimiento seguro para eliminar kernels antiguos en Ubuntu. Nunca elimine el kernel que uname -r muestra actualmente.

FAQ

¿La aplicación de parches en vivo al kernel significa que nunca tengo que reiniciar mi VPS?

No. Los parches en vivo 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 conserva 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 se retira la serie del kernel, y las correcciones de gravedad media del kernel nunca se aplican mediante parches en vivo. Programe reinicios de mantenimiento con la periodicidad que elija, en lugar de esperar a que se fuerce uno.

¿Cómo compruebo si la aplicación de parches en vivo al kernel está aplicando realmente los parches?

Ejecute sudo canonical-livepatch status y lea dos líneas. kernel state informa de si el servicio cubre la serie del kernel en ejecución, y patch state informa de 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 en ese momento no hay nada parcheado en memoria, 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», y que el límite aumenta a 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, a continuación, 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 en vivo 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, el proyecto original puede haber modificado una estructura de datos, algo que la aplicación de parches en vivo no puede hacer de forma segura en objetos ya asignados. Ambos casos se resuelven de la misma manera: instale el paquete actualizado del kernel e inicie el sistema con ese kernel.

¿Qué no cubre en absoluto la aplicación de parches en vivo al kernel?

El espacio de usuario. Canonical lo especifica claramente: Livepatch «no aplica parches a bibliotecas del espacio de usuario como OpenSSL o glibc, porque esa tarea corresponde a unattended-upgrades o a una herramienta de administración de sistemas». Tampoco puede proporcionar una versión nueva del kernel ni una función nueva, ya que sólo reemplaza cuerpos de funciones dentro de la serie que ya está en ejecución. 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á operativo.