Patching do kernel em tempo real ou reboot na VPS?

O que a aplicação de patches ao kernel em tempo real faz numa VPS

A aplicação de patches ao kernel em tempo real aplica correções de segurança do kernel numa máquina em execução, sem reboot e sem interromper ligações. Uma cópia corrigida de uma função é carregada como módulo do kernel, e cada chamada à função antiga é redirecionada para a nova cópia enquanto o servidor continua a processar tráfego. Este mecanismo explica tanto para que serve a aplicação de patches em tempo real como o que ela não consegue fazer.

Ela ganha tempo. Não elimina a necessidade de reboot. Um servidor ao qual foram aplicados patches em tempo real durante seis meses continua arrancado com a imagem antiga do kernel no disco, e cada um desses patches existe apenas na memória.

A aplicação de patches em tempo real é frequentemente apresentada como uma funcionalidade de um plano gerido. Num servidor não gerido, pode ativá-la por sua conta com dois comandos. É importante saber isto antes de pagar pela diferença entre uma VPS gerida e uma VPS não gerida.

Como funciona a aplicação dinâmica de patches ao kernel?

O kernel tem um núcleo integrado para aplicação dinâmica de patches, compilado com CONFIG_LIVEPATCH. Verifique se o kernel em execução o inclui:

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

Uma linha com CONFIG_LIVEPATCH=y significa que o kernel em execução foi compilado com esse núcleo. Sem ele, nenhum serviço de aplicação dinâmica de patches pode fazer alterações nessa máquina.

O redirecionamento usa ftrace, o rastreador de funções do kernel. A maioria das funções do kernel é compilada com uma instrução de chamada no início da função, antes de os argumentos ou a pilha serem modificados. O ftrace usa esse ponto de chamada como hook. Quando um patch é aplicado, o núcleo de aplicação dinâmica de patches regista um handler do ftrace na função de destino, e esse handler encaminha a execução para a função de substituição. A documentação do kernel explica isto de forma direta: "A aplicação dinâmica de patches normalmente precisa redirecionar o código no início da entrada da função, antes de os parâmetros da função ou a pilha serem modificados."

Desta frase resultam duas consequências, e ambas serão importantes mais adiante. Só é possível aplicar patches a uma função que o ftrace consiga interceptar. Portanto, uma função compilada sem essa chamada de entrada não pode ser corrigida. Além disso, a unidade de aplicação do patch é sempre uma função completa, nunca uma única linha dentro dela.

A parte mais difícil é alterar um sistema em execução com segurança. Se o código antigo ainda estiver na pilha de algum CPU quando a função for trocada, o sistema passa a combinar comportamentos antigos e novos. O Linux upstream resolve isto com um modelo de consistência por tarefa, descrito na documentação do kernel como híbrido: "usa a consistência por tarefa e a comutação por barreira de chamadas de sistema do kGraft, combinadas com a comutação de rastreamentos da pilha do kpatch." As tarefas passam para o código novo uma de cada vez, apenas quando o kernel consegue confirmar que a tarefa não está atualmente dentro de uma função corrigida. Enquanto nem todas as tarefas tiverem mudado, o patch está em transição.

Pode ver o resultado diretamente. Os patches aplicados aparecem em /sys/kernel/livepatch, num diretório por patch, com as funções corrigidas listadas no interior.

ls /sys/kernel/livepatch/

Uma listagem vazia significa que não há nenhum patch dinâmico do kernel carregado na memória. Num servidor novo, este é o estado inicial normal.

O que a aplicação de patches no kernel em execução não pode corrigir

Os corpos das funções são corrigidos. Todo o resto permanece inalterado.

• Estruturas de dados alteradas. Se a correção upstream adicionar um campo a uma struct ou alterar o significado de um campo existente, não existe uma forma segura de reescrever objetos que já foram alocados e estão em uso. O projeto kpatch declara diretamente o caso equivalente: "Patches which modify statically allocated data are not directly supported." Variáveis shadow e callbacks podem servir como solução alternativa, mas são escritos manualmente para cada patch e não são automáticos.
• Correções distribuídas por várias funções ao mesmo tempo. Uma correção que altere a ordem de aquisição de locks num grupo de funções precisa de alterar todas elas em conjunto, e o modelo de consistência muda as tarefas em vez de congelar toda a máquina num único instante.
• Código de inicialização. As funções marcadas com __init já foram executadas e libertadas quando o servidor está ativo, por isso já não há nada para redirecionar.
• Novas versões do kernel e novas funcionalidades. A aplicação de patches em execução permite avançar entre níveis de patch dentro da mesma série do kernel. Nunca permite passar de uma série para outra e nunca adiciona uma funcionalidade. Se precisar de algo de uma série mais recente, como as alterações incluídas no Linux 7.1, instale esse kernel e faça boot com ele.
• Userspace. A Canonical define explicitamente este limite: "Canonical Livepatch does not patch userspace libraries like OpenSSL or glibc, because that is the responsibility of unattended-upgrades or a systems management tool." Um kernel com live patching ao lado de um OpenSSL desatualizado não é um servidor corrigido, por isso mantenha o unattended-upgrades a gerir os pacotes do userspace nessa mesma máquina.

Existe também um limite de severidade no serviço da Ubuntu. A Canonical afirma que ele "patches kernel vulnerabilities with critical and high Common Vulnerability Scoring System (CVSS) and Ubuntu Priority ratings." Um identificador CVE (common vulnerabilities and exposures) identifica uma vulnerabilidade, e o CVSS é a pontuação associada a ela. Uma CVE do kernel com classificação média é corrigida no pacote armazenado em disco e não é corrigida em execução, por isso só chega ao kernel em execução no próximo reboot.

Quais são as opções de aplicação de patches no kernel em execução?

Existem três linhagens usadas habitualmente, e todas utilizam os mesmos mecanismos do kernel.

Canonical Livepatch é disponibilizado através do Ubuntu Pro. O Ubuntu Pro é gratuito para uso pessoal, e a formulação da Canonical é que ele "is and always will be free for personal use on up to 5 physical machines", aumentando para 50 máquinas no caso de membros oficiais da Ubuntu Community. Esse é o limite documentado em agosto de 2026. O uso comercial exige uma subscrição paga. A cobertura é concedida por série e variante do kernel. Ela inclui os kernels de disponibilidade geral (GA) das versões de suporte de longo prazo (LTS) suportadas, bem como os respetivos kernels de habilitação de hardware (HWE), em variantes como generic, aws, azure, gcp, oracle, ibm e lowlatency. Compare o seu kernel com a lista de kernels publicada pela Canonical antes de depender deste serviço.

KernelCare, da TuxCare, é um agente comercial que abrange muitas distribuições, incluindo algumas sem um serviço do próprio fornecedor. A instalação documentada usa um script do fornecedor, curl -s -L https://kernelcare.com/installer | bash, seguido de /usr/bin/kcarectl --register KEY para uma licença baseada em chave. Depois, o agente procura novos patches segundo o seu próprio agendamento, e /usr/bin/kcarectl --update força uma verificação. Leia o instalador antes de o enviar para uma shell num servidor que seja importante para si.

kpatch e kGraft são os antecessores. O kGraft veio da SUSE, o kpatch veio da Red Hat, e o núcleo da aplicação de patches em execução no Linux upstream atual resulta da combinação das duas ideias. O próprio kpatch está a ser descontinuado: o README indica que, a partir do Linux 6.19, "the kpatch project is deprecated and in maintenance mode", com kpatch-build a ser substituído por klp-build no kernel upstream. No RHEL e nas suas reconstruções, a opção adequada é o serviço da própria distribuição, em vez de criar patches manualmente.

Escolha com base no que a sua distribuição suporta e no que a sua licença permite. O resultado ao nível do kernel é o mesmo em todos os casos.

Como ativar o Canonical Livepatch no Ubuntu

Primeiro, obtenha um token na página da sua conta Ubuntu Pro. Ambos os comandos abaixo precisam de acesso de saída à rede, porque o cliente comunica com os servidores da Canonical para associar a máquina à conta e obter patches.

sudo pro attach TOKEN
sudo pro status

Executar sudo pro attach sem um token inicia um fluxo baseado no navegador e apresenta um código para introduzir no site da Canonical. A associação ativa automaticamente os serviços recomendados. Numa versão LTS atual, isso inclui o Livepatch. Use sudo pro attach --no-auto-enable se preferir escolher os serviços manualmente.

Se o Livepatch ainda não estiver ativado:

sudo pro enable livepatch
sudo canonical-livepatch status

O serviço é executado a partir do snap canonical-livepatch. Por isso, o snapd tem de estar a funcionar para que a ativação termine. pro status apresenta uma tabela com os serviços, a respetiva autorização e o estado. canonical-livepatch status apresenta os detalhes por kernel. A documentação da Canonical mostra o resultado neste 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

Duas linhas contêm a resposta. kernel state indica se a série que está a executar é abrangida pelo serviço. É essa linha que muda para um estado negativo quando inicia um kernel que o Livepatch não suporta. patch state indica se os patches aplicáveis a esse kernel foram efetivamente carregados. Um kernel abrangido sem patches aplicados indica um problema no cliente. Um kernel não abrangido indica um problema no kernel. Nenhuma definição do cliente resolve esse caso.

Como saber se há um reboot pendente?

A aplicação de patches no kernel em execução elimina a urgência, por isso um reboot pendente deixa de ser óbvio. É preciso procurá-lo.

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

O gestor de pacotes cria /var/run/reboot-required quando um pacote instalado precisa de um reboot para que a alteração tenha efeito, e um novo pacote linux-image cria sempre esse ficheiro. O ficheiro .pkgs lista os pacotes que fizeram esse pedido. Se o primeiro comando responder No such file or directory, nenhum pacote pediu um reboot desde o último arranque da máquina. Nas versões atuais do Ubuntu, /var/run é um link simbólico para /run, por isso ambos os caminhos acedem ao mesmo ficheiro.

Esse sinalizador reside num tmpfs e é reposto em cada arranque. Por isso, confirme-o diretamente no kernel:

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

uname -r mostra o kernel em execução. O segundo comando mostra os pacotes do kernel instalados no disco. Um linux-image dessa lista que seja mais recente do que o kernel indicado por uname -r significa que a máquina está a executar um kernel antigo, independentemente do estado do Livepatch. Esta é a verificação relevante, porque a aplicação de patches no kernel em execução foi concebida para o manter seguro, não para o manter atualizado.

Para a parte do espaço de utilizador da mesma questão, needrestart é instalado por predefinição no Ubuntu Server e lista os serviços em execução que ainda mantêm abertos ficheiros de bibliotecas eliminados.

sudo needrestart -r l

O par de opções -r l significa "listar apenas", por isso o comando apenas mostra informações e não altera nada.

Por que o reboot nunca deixa de ser necessário

O kernel no disco não é alterado. Os live patches são carregados no kernel em execução e nunca são gravados na imagem de boot. Por isso, um reboot inicia o sistema com o linux-image escolhido pelo bootloader, e o cliente Livepatch reaplica os patches que ainda se aplicam. Entre esses dois momentos, o sistema executa código sem patches. Esse é mais um motivo para iniciar um kernel atual, e não um kernel antigo.

A cobertura é específica de cada série de kernels, e as séries deixam de ser suportadas. Quando a série em execução sai da lista de versões suportadas, a linha kernel state deixa de indicar cobertura. A única correção é usar um kernel mais recente. Isso exige um reboot. Numa versão LTS, a nova série normalmente chega como um kernel de habilitação de hardware incluído numa versão de ponto como 26.04.1. Assim, o substituto já está no arquivo de pacotes. Só falta fazer o boot no momento que você agendar.

As correções de kernel de severidade média e baixa nunca são aplicadas por live patch. Elas permanecem no pacote armazenado no disco e só entram em uso quando você inicia o sistema com esse kernel.

Kernels que permanecem em execução por muito tempo também acumulam estado que o patching não limpa. Vale citar a posição da própria Canonical, porque é a mais direta: o Livepatch "não substitui o reboot. É uma ferramenta que dá mais controle ao evitar reboots não agendados." A palavra que concentra o significado é não agendados. Você ainda faz reboot. Você escolhe quando.

Como agendar uma reinicialização e garantir que o sistema volte a funcionar

Uma reinicialização de VPS é um processo sem retorno se não conseguir aceder à consola. Antes de executar reboot, confirme que consegue voltar a aceder ao sistema se a máquina não arrancar.

• Confirme se o seu provedor disponibiliza uma consola serial ou uma vista VNC (virtual network computing) no painel de controlo. Abra-a agora, não durante a indisponibilidade.
• Verifique o espaço livre com df -h /boot. Um /boot cheio faz o pacote do kernel falhar ao escrever o seu initramfs (initramfs inicial), o que pode deixar uma entrada do bootloader a apontar para uma imagem que nunca foi concluída.
• Mantenha instalado pelo menos um kernel antigo conhecido por funcionar. O GRUB apresenta-o em "Advanced options for Ubuntu". Arrancar com esse kernel é a forma mais rápida de recuperar quando um kernel novo falha.
• Identifique o modo de recuperação do seu provedor antes de precisar dele. Se a consola apresentar uma linha de comandos do initramfs depois da reinicialização, é aí que a reparação deve ser feita.

Depois, reinicialize num horário em que esteja acordado:

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

Isto agenda a reinicialização para daqui a cinco minutos e envia uma mensagem aos utilizadores com sessão iniciada. sudo shutdown -c cancela a reinicialização. Quando a máquina voltar, confirme ambas as partes:

uname -r
sudo canonical-livepatch status

uname -r deve agora indicar o kernel mais recente, e o estado deve indicar que a nova série está coberta. Se a máquina não voltar a funcionar, a falha está quase sempre no processo de arranque, não na rede. Nesse caso, use o procedimento indicado em o guia para uma VPS que não arranca depois de uma atualização do kernel.

Por que kernels antigos ainda precisam ser removidos

O live patching agrava este problema, em vez de o resolver, porque elimina a necessidade de reiniciar enquanto os pacotes linux-image continuam a ser instalados. Cada kernel instala uma imagem de arranque, um initramfs, uma árvore de módulos e, normalmente, um pacote de headers. Numa VPS pequena com uma partição /boot separada de algumas centenas de megabytes, três ou quatro kernels ocupam todo o espaço.

Um /boot cheio impede a instalação do kernel seguinte. É assim que uma máquina pode ficar incapaz de instalar precisamente a atualização de que precisa. O caminho apt autoremove remove kernels antigos quando estes se tornam elegíveis. Porém, num sistema que nunca reinicia, eles nem sempre são elegíveis, porque o gestor de pacotes não remove um kernel que ainda possa estar em execução.

Por isso, verifique o que está instalado, mantenha o kernel em execução e uma alternativa conhecida como funcional e remova os restantes usando o procedimento seguro para remover kernels antigos no Ubuntu. Nunca remova o kernel que uname -r indica como atualmente em execução.

FAQ

O live patching do kernel significa que nunca preciso de reiniciar o meu VPS?

Não. Os live patches são carregados no kernel em execução e não são escritos na imagem de arranque, por isso o linux-image no disco permanece na versão com que arrancou. A Canonical afirma-o diretamente: o Livepatch "não substitui o reinício. É uma ferramenta que lhe dá mais controlo, evitando reinícios não agendados." A cobertura também termina quando a sua série do kernel é descontinuada, e as correções do kernel de severidade média nunca são aplicadas com live patching. Agende um reinício de manutenção com a periodicidade que escolher, em vez de esperar que seja forçado.

Como verifico se o live patching do kernel está realmente a aplicar correções?

Execute sudo canonical-livepatch status e leia duas linhas. kernel state indica se a série do kernel em execução está abrangida pelo serviço, e patch state indica se as correções para esse kernel estão carregadas. Também pode verificar diretamente o lado do kernel com ls /sys/kernel/livepatch/, que lista um diretório por cada patch carregado. Uma listagem vazia significa que nada está corrigido na memória neste momento, independentemente do que o cliente indicar.

O Ubuntu Pro é gratuito num VPS pessoal?

Sim, dentro de um limite documentado. A Canonical afirma que o Ubuntu Pro "é e será sempre gratuito para utilização pessoal em até 5 máquinas físicas", aumentando para 50 máquinas no caso de membros oficiais da Ubuntu Community, em agosto de 2026. A utilização comercial requer uma subscrição paga. Associe uma máquina com sudo pro attach TOKEN, utilizando um token da página da sua conta Ubuntu Pro, e ative depois o serviço com sudo pro enable livepatch.

Por que motivo uma CVE do kernel continua listada como não corrigida depois de o Livepatch ser executado?

Normalmente, por um de dois motivos. A correção pode estar abaixo do limiar de severidade, porque a Canonical aplica live patches às "vulnerabilidades do kernel com classificações críticas e elevadas no Common Vulnerability Scoring System (CVSS) e nas classificações de prioridade do Ubuntu", deixando as restantes para o pacote instalado no disco. Ou a correção pode não ser expressável como uma alteração ao corpo de uma função, por exemplo quando o upstream alterou uma estrutura de dados, algo que o live patching não consegue fazer com segurança em objetos já alocados. Em ambos os casos, a solução é a mesma: instale o pacote atualizado do kernel e arranque com ele.

O que é que o live patching do kernel não cobre de todo?

O espaço de utilizador. A Canonical é explícita ao indicar que o Livepatch "não aplica patches a bibliotecas do espaço de utilizador, como OpenSSL ou glibc, porque essa é a responsabilidade do unattended-upgrades ou de uma ferramenta de gestão de sistemas." Também não consegue fornecer uma nova versão do kernel nem uma nova funcionalidade, pois apenas substitui corpos de funções dentro da série que já está em execução. E não consegue aplicar patches a funções __init, que já foram executadas e libertadas da memória quando o servidor está ativo.