Live patching ou reboot na VPS: qual usar?

O que a aplicação dinâmica de patches ao kernel faz numa VPS

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

Ganha tempo. Não elimina a necessidade de fazer reboot. Um servidor ao qual foram aplicados patches dinâmicos durante seis meses continua a arrancar com a imagem antiga do kernel no disco, e cada um desses patches existe apenas na memória.

A aplicação dinâmica de patches é frequentemente apresentada como uma funcionalidade de um plano gerido. Num servidor não gerido, pode ativá-la sozinho com dois comandos. É importante saber isto antes de pagar a diferença entre uma VPS gerida e uma VPS não gerida.

Como funciona o live patching do kernel?

O kernel tem um núcleo integrado de live patching, compilado com CONFIG_LIVEPATCH. Verifique se o kernel em execução inclui esse recurso:

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

Uma linha com CONFIG_LIVEPATCH=y significa que o kernel em execução foi compilado com o núcleo presente. Sem esse núcleo, nenhum serviço de live patching consegue 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 stack serem alterados. O ftrace usa esse ponto de chamada como hook. Quando um patch é aplicado, o núcleo de live patching regista um handler do ftrace na função-alvo, e o handler encaminha a execução para a função de substituição. A documentação do kernel explica de forma direta: "O live patching normalmente precisa redirecionar o código logo no início da entrada da função, antes de os parâmetros da função ou a stack serem alterados de qualquer forma."

Essa frase tem duas consequências, e ambas serão importantes mais adiante. Só é possível aplicar um patch a uma função que possa ser interceptada pelo ftrace. Portanto, uma função compilada sem essa chamada de entrada não pode ser corrigida. Além disso, a unidade de patching é sempre uma função inteira, 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 a ser executado na stack de algum CPU quando a função for trocada, haverá uma mistura de comportamentos antigos e novos. O Linux upstream trata esta situação com um modelo de consistência por tarefa, descrito na documentação do kernel como um modelo híbrido: "usa a consistência por tarefa e a alternância por barreira de chamadas de sistema do kGraft, combinadas com a alternância baseada no stack trace 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. Até todas as tarefas terem mudado, o patch está em transição.

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

ls /sys/kernel/livepatch/

Uma listagem vazia significa que não há nenhum live patch carregado na memória. Num servidor novo, esse é o estado inicial normal.

O que o live kernel patching não consegue corrigir

Os corpos das funções são corrigidos. Todo o resto fica 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 os 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." Shadow variables e callbacks existem 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 dos locks num grupo de funções precisa de alterar todas essas funções em conjunto, e o modelo de consistência troca 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á em funcionamento. Por isso, já não há nada para redirecionar.
• Novas versões do kernel e novas funcionalidades. O live patching move o sistema entre níveis de patch dentro da mesma série do kernel. Nunca o move de uma série para outra e nunca adiciona uma funcionalidade. Se quiser 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 o limite desta forma: "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 significa que o servidor esteja corrigido. Por isso, mantenha o unattended upgrades a tratar dos pacotes do userspace no mesmo servidor.

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 falha, e o CVSS é a pontuação associada a ela. Uma CVE do kernel classificada como média é corrigida no pacote armazenado no disco e não recebe live patching. Assim, chega ao kernel em execução no próximo reboot, e não antes.

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

Há três linhagens usadas com frequência, 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 "é e sempre será gratuito para uso pessoal em até 5 máquinas físicas", 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 de kernel e por variante, abrangendo os kernels de disponibilidade geral (GA) das versões de suporte de longo prazo (LTS) suportadas, além dos 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 cobre muitas distribuições, incluindo algumas sem um serviço próprio. 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 verifica novos patches segundo o seu próprio agendamento, e /usr/bin/kcarectl --update força uma verificação. Leia o instalador antes de o encaminhar para uma shell num servidor importante.

kpatch e kGraft são os antecessores. O kGraft veio da SUSE, o kpatch veio da Red Hat, e o núcleo de aplicação de patches em tempo real do 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, "o projeto kpatch está obsoleto e em modo de manutenção", com kpatch-build a ser substituído por klp-build no kernel upstream. No RHEL e nas respetivas reconstruções, use o serviço da própria distribuição em vez de criar patches manualmente.

Escolha com base no suporte da sua distribuição 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

Obtenha primeiro 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 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, que numa versão LTS atual incluem o Livepatch. Use sudo pro attach --no-auto-enable se preferir escolher os serviços manualmente.

Se o Livepatch ainda não estiver ativo:

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 operacional para a ativação terminar. pro status apresenta uma tabela dos serviços, com a respetiva elegibilidade e estado. canonical-livepatch status apresenta os detalhes por kernel, e a documentação da Canonical mostra um resultado com 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

Duas linhas contêm a resposta. kernel state indica se a série que está a executar é abrangida pelo serviço, e é a linha que passa a indicar um problema 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, e nenhuma configuração do cliente o resolve.

Como saber se existe um reboot pendente?

O live patching elimina a urgência, por isso um reboot pendente deixa de ser evidente. É necessário 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 restart para que a alteração tenha efeito. A instalação de 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 indicador fica num tmpfs e é reposto em cada arranque. Por isso, confirme-o no próprio kernel:

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

uname -r mostra o kernel em execução. O segundo comando mostra os pacotes de kernel instalados no disco. Se existir na lista um linux-image mais recente do que o kernel indicado por uname -r, a máquina está a executar um kernel antigo, independentemente do estado do Livepatch. Esta é a verificação importante, porque o live patching foi concebido para manter seguro o kernel em execução, não para o manter atualizado.

Para a parte do espaço de utilizador da mesma verificaçã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 flags -r l significa "listar apenas". Por isso, apenas apresenta informação 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 kernel que o linux-image seleciona, e o cliente Livepatch reaplica os patches que ainda são aplicáveis. Entre esses dois momentos, o sistema executa código sem patches. Esse é mais um motivo para arrancar com um kernel atual, e não com um antigo.

A cobertura é definida por série de kernel, e as séries deixam de ser mantidas. Quando a série em execução deixa de estar na lista de séries suportadas, a linha kernel state deixa de indicar a cobertura. A única correção é usar um kernel mais recente. Isso exige um reboot.

As correções de kernel de severidade média e baixa nunca recebem live patch. Elas permanecem no pacote armazenado no disco e só ficam ativas quando o sistema arranca com esse kernel.

Kernels que permanecem em execução durante muito tempo também acumulam estado que o patching não limpa. Vale citar a posição da própria Canonical, porque é a mais clara: o Livepatch "não substitui o reboot. É uma ferramenta que oferece mais controlo ao evitar reboots não programados." A palavra essencial é não programados. Ainda é necessário fazer reboot. Você escolhe quando.

Como agendar um reboot que termine com o sistema novamente disponível

Um reboot de uma VPS é uma operação sem retorno se não conseguir aceder à consola. Antes de executar reboot, confirme que consegue voltar a entrar se a máquina não arrancar corretamente.

• Confirme se o seu provedor disponibiliza uma consola serial ou uma vista VNC (virtual network computing) no painel de controlo e abra-a agora, não durante a indisponibilidade.
• Verifique o espaço livre com df -h /boot. Um /boot cheio faz com que o pacote do kernel falhe ao escrever o seu initramfs (initial RAM filesystem), 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 que saiba estar funcional. O GRUB apresenta-o em "Advanced options for Ubuntu", e arrancar com ele é a forma mais rápida de recuperar quando um kernel novo falha.
• Identifique o rescue mode do seu provedor antes de precisar dele. Se a consola apresentar uma prompt do initramfs depois do reboot, é nesse ambiente que a reparação deve ser feita.

Depois, faça o reboot num horário em que esteja acordado:

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

Isto agenda o reboot para cinco minutos depois e envia uma mensagem aos utilizadores com sessão iniciada. sudo shutdown -c cancela a operação. Quando a máquina voltar, confirme as duas 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á abrangida. Se a máquina não voltar de todo, a falha está quase sempre no caminho de arranque, não na rede, e o procedimento de recuperação é o indicado em 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.

Uma partição /boot cheia impede a instalação do kernel seguinte. É assim que uma máquina pode deixar de conseguir instalar precisamente a atualização de que precisa. O processo apt autoremove remove kernels antigos quando estes se tornam elegíveis. Porém, numa máquina que nunca é reiniciada, eles nem sempre ficam 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 estando atualmente em execução.

FAQ

A aplicação de patches live ao kernel significa que nunca tenho de reiniciar o meu VPS?

Não. Os patches live são carregados no kernel em execução e não são escritos na imagem de arranque, pelo que o linux-image em disco permanece na versão com que o sistema arrancou. A Canonical afirma-o diretamente: o Livepatch "is not a replacement for rebooting. It is a tool that gives you more control by preventing unscheduled reboots." A cobertura também termina quando a sua série do kernel é retirada de manutenção, e as correções do kernel de severidade média nunca são aplicadas por live patch. Agende um reboot de manutenção com a periodicidade que escolher, em vez de esperar que seja imposto.

Como verifico se a aplicação de patches live ao kernel está realmente a aplicar patches?

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 os patches para esse kernel estão carregados. Também pode verificar diretamente o lado do kernel com ls /sys/kernel/livepatch/, que apresenta um diretório por cada patch carregado. Uma listagem vazia significa que não há nada aplicado na memória neste momento, independentemente do que o cliente indique.

O Ubuntu Pro é gratuito num VPS pessoal?

Sim, dentro de um limite documentado. A Canonical afirma que o Ubuntu Pro "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, em agosto de 2026. A utilização comercial requer uma subscrição paga. Associe uma máquina com sudo pro attach TOKEN, usando um token da página da sua conta Ubuntu Pro, e ative o serviço com sudo pro enable livepatch.

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

Normalmente, por uma de duas razões. A correção pode estar abaixo do limiar de severidade, porque a Canonical aplica live patches a "kernel vulnerabilities with critical and high Common Vulnerability Scoring System (CVSS) and Ubuntu Priority ratings" e deixa as restantes para o pacote em 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 a aplicação de patches live não consegue fazer com segurança em objetos já alocados. Em ambos os casos, a solução é a mesma: instale o pacote de kernel atualizado e arranque o sistema com ele.

O que é que a aplicação de patches live ao kernel não abrange de todo?

O userspace. A Canonical é explícita ao afirmar que o Livepatch "does not patch userspace libraries like OpenSSL or glibc, because that is the responsibility of unattended-upgrades or a systems management tool." Também não consegue fornecer uma nova versão do kernel nem uma funcionalidade nova, porque apenas substitui corpos de funções dentro da série que já está em execução. Além disso, não consegue aplicar patches a funções __init, que já foram executadas e libertadas da memória quando o servidor está ativo.