Siga ZDNET: Adicione-nos como fonte preferencial no Google.
Principais conclusões da ZDNET
- O Linux tem um novo problema de inicialização segura.
- Mas não é tão ruim quanto algumas pessoas pensam.
- Aqui está o que você pode fazer para resolver o problema.
No last dos anos 2000, o firmware do computador estava migrando do BIOS legado para a UEFI Unified Extensible Firmware Interface (UEFI). Junto com ele veio o Safe Boot. Esse mecanismo de segurança com suporte da Microsoft foi projetado para impedir bootkits e malware em nível de firmware que a segurança tradicional do sistema operacional não conseguia detectar. A inicialização segura foi confusa, mas funcionou. Para pessoas que tentam instalar e executar Linux em PCs com Home windows, essa configuração foi um verdadeiro incômodo. Aqui estamos, 14 anos após o aparecimento do Safe Boot em PCs com Home windows 8, e mais uma vez tem o potencial de causar uma verdadeira dor de cabeça aos usuários do Linux.
Mais uma vez, alguns amantes do Linux estão em pânico porque “a Microsoft está bloqueando o Linux!” Não é isso que está acontecendo. Como a Microsoft apontou, “Os certificados de inicialização segura sempre tiveram datas de expiração.” Sim, sim, eles têm. Além disso, como Ed Bott observou recentemente, embora não seja tão irritante para os usuários do Home windows, algumas pessoas ainda podem ter problemas com a expiração dos certificados de inicialização segura.
A boa notícia é que essa preocupação não é um evento apocalíptico para o Linux. Seus sistemas existentes não vão acordar uma manhã e se recusar a inicializar só porque uma knowledge acabou. Mas isso é um momento de verdade sobre como o mundo Linux tem lidado com a inicialização segura por mais de uma década e uma oportunidade para os usuários assumirem mais controle, em vez de esperar silenciosamente que a Microsoft e os OEMs mantenham as luzes acesas para sempre.
Além disso: testei novamente a melhor alternativa para MacOS no Linux – e agora ele até imita o Liquid Glass
Vamos ver o que realmente está acontecendo, por que o Linux está envolvido e o que você deveria fazer antes de 2026 e além.
Um velho compromisso vem devido
Para entender o porquê, é preciso voltar de 2011 a 2012, quando o UEFI Safe Boot chegou pela primeira vez aos PCs do mercado de massa. O objetivo do design parecia razoável: impedir a execução de código não confiável antes o sistema operacional fazendo com que o firmware verifique assinaturas de bootloaders, kernels e ROMs opcionais.
Na prática, porém, a Microsoft definiu efetivamente as raízes de confiança para quase todos os PCs de consumo. Em vez de criar – ou fazer com que os usuários criem – chaves e certificados de inicialização segura, a maioria dos fornecedores de {hardware} envia máquinas com um conjunto de chaves e certificados incorporados no firmware. A maioria dessas chaves e certificados eram “UEFI CA de terceiros da Microsoft” que podiam assinar bootloaders de terceiros. As distribuições que queriam “apenas inicializar” nesses sistemas sem pedir aos usuários que alternassem interruptores de firmware obscuros basicamente tinham duas opções:
- Envie instruções para os usuários desativarem a inicialização segura.
- Ou jogue junto e obtenha um pequeno bootloader de primeiro estágio (shim) assinado pela UEFI CA da Microsoft.
A maioria das principais distribuições Linux escolheu shim. Matthew Garrett, um conhecido programador Linux, criou a abordagem shim, e ela ainda é usada hoje.
Essa abordagem foi um compromisso pragmático: a Microsoft verifica o shim, o shim verifica o restante da cadeia de inicialização do Linux e os usuários não precisam editar manualmente os bancos de dados de chaves UEFI ou desativar recursos de segurança.
Além disso: o subsistema Home windows para Linux oferece aos desenvolvedores um motivo convincente para continuar com a Microsoft – aqui está o porquê
Esse compromisso funcionou extraordinariamente bem. Por mais de uma década, você pôde comprar um laptop computer aleatório, ativar o Safe Boot e inicializar o Fedora, Ubuntu, openSUSE, Debian, RHEL e outros, tudo graças à chave da Microsoft armazenada em seu firmware e a um binário shim assinado pela Microsoft em sua partição de sistema EFI.
Mas os certificados, ao contrário dos compromissos, têm datas de validade.
O que expira em 2026?
A raiz do drama de hoje é que os certificados de 2011 que a Microsoft tem usado para assinar os componentes do Safe Boot estão chegando ao fim do seu período de validade formal. Vários dos certificados Microsoft Safe Boot da period 2011 chegam ao fim da vida útil em 2026, em duas ondas principais (meados do ano e no last do ano).
Para resolver esse problema, a Microsoft criou um novo conjunto de certificados de inicialização segura em 2023 e começou a distribuí-los para OEMs e plataformas. As atualizações de firmware devem fazer o trabalho silencioso: adicionar novas chaves, manter as antigas para compatibilidade e garantir que futuros componentes de inicialização possam ser validados.
Além disso: a Microsoft continua seu grande impulso no Linux no Construct 2026
Para lojas somente Home windows, este é principalmente um trabalho de correção automático. Para o mundo Linux, é uma história diferente,
Quando as pessoas ouvem “expiração do certificado”, elas tendem a imaginar algo como um certificado SSL: uma vez passada a knowledge “notAfter”, os clientes se recusam a falar com o servidor. Esse modelo psychological faz 2026 parecer um precipício: chega o dia 24 de junho e, de repente, sua distro não inicializa.
A inicialização segura não funciona dessa maneira. Se o seu firmware já confia no Microsoft UEFI CA 2011 hoje, é quase certo que continuará a confiar nele depois que o calendário entrar na janela de expiração. As instalações existentes do Linux, com seus shim e bootloaders existentes, continuarão a inicializar como sempre. Nada irá magicamente bloquear-se à meia-noite.
Aqui está o problema
O problema não é seu presente bota; é seu futuro bota. Se o firmware do seu PC antigo nunca Se você obtiver as chaves de 2023 e o resto do mundo começar a presumir que essas chaves existem, você pode acabar preso em um limbo estranho. Embora sua instalação existente do Linux ainda inicialize, uma distribuição nova ou atualizada não.
Também: Microsoft surpreende com sua primeira distribuição Linux de servidor: Azure Linux 4.0
Esperançosamente, o fornecedor do seu PC enviará firmware com as novas chaves, as distribuições Linux atualizarão seus shims para serem compatíveis com as novas chaves e tudo dará certo. Deveríamos ter muita sorte.
Aqui está o que fazer:
1. Atualize seu firmware
Todos os principais fornecedores têm enviado atualizações que, entre outras coisas, adicionam ou ajustam chaves de inicialização segura em resposta aos certificados 2023 da Microsoft e às próximas expirações. Você não precisa saber os IDs exatos das chaves para se beneficiar; você precisa ter certeza de que seu sistema recebe essas atualizações.
Em uma máquina Linux típica, essa abordagem significa verificar o website de suporte do seu fornecedor para atualizações de BIOS/UEFI lançadas nos últimos dois anos. Em muitos sistemas, você pode usar a pilha de atualização de firmware do Linux, fwupdpara lidar com isso em sua distribuição. Para realizar esta etapa, execute os seguintes comandos como usuário root:
- atualização do fwupdmgr
- atualizações do fwupdmgr
- atualização do fwupdmgr
Se o seu {hardware} for compatível, essas etapas extrairão cápsulas de firmware e atualizações UEFI db/dbx que incluem os novos certificados Microsoft Safe Boot. Após a atualização, você precisará reiniciar uma ou duas vezes; o firmware será atualizado e pronto.
Também: Meus 5 principais desktops Linux de 2026 (até agora) – e experimentei todos eles
Em alguns sistemas mais antigos, talvez você ainda exact baixar um .exe ou .iso do fornecedor e seguir sua dança. Esse procedimento é irritante, mas é uma tarefa única que proporciona anos de comportamento mais suave da inicialização segura.
2. Verifique como sua distribuição lida com certificados
A maioria das distribuições Linux convencionais já considerou a expiração de 2026 e concluiu que não é uma emergência, mas algo a ser abordado com cuidado.
Muitas distribuições estão alinhando suas construções de shim e processos de assinatura para permanecerem compatíveis durante a transição. Se você estiver em uma versão moderna de uma distribuição de grande nome e seu firmware estiver atualizado, há grandes probabilities de que “simplesmente funciona” proceed a ser verdade.
Para você, o teste mais simples é também o mais prático:
Faça este teste uma vez agora, para saber como será o novo regular. Se uma imagem futura falhar ao inicializar com o Safe Boot habilitado, você poderá saber se a regressão está no firmware (chaves não atualizadas), na imagem da distribuição ou em uma interação desagradável entre os dois.
Também: Depois de 30 anos com Linux, dei uma probability ao Home windows 11 – e encontrei 9 problemas claros
Muitas das distribuições Linux mais populares já resolveram o problema de inicialização segura. A Red Hat publicou orientações dedicadas sobre inicialização segura expiração e mantém pilhas de shim/bootloader RHEL/Fedora que são assinadas e alinhadas com o modelo de confiança da Microsoft. A família Ubuntu da Canonical há muito oferece suporte completo ao Safe Boot. Os instaladores e kernels atuais do Ubuntu estão assinados sob a UEFI CA de terceiros existente da Microsoft.
SUSE e openSUSE também estão prontos para usar as novas CAs. Infraestrutura de inicialização segura do Debian é importante porque seu shim é usado por muitas distros e foi desenvolvido por uma equipe cruzada de distros. Algumas distribuições Linux, no entanto, como Arch e seus parentes não facilitam o suporte ao Secure Boot.
A solução alternativa tentadora
Se você ficar nos fóruns do Linux por tempo suficiente, verá o mesmo conselho repetido sempre que o Safe Boot aparecer: “Se houver problemas, apenas desative o Safe Boot”.
Entendo. Eu mesmo fiz isso. Inicialização segura tem tem sido uma dor desde que apareceu pela primeira vez. Para muitos usuários, o caminho mais fácil tem sido desligá-lo e fazer o problema desaparecer.
O perigo é quando o hack temporário se torna permanente. Com o Safe Boot desabilitado, você perde a defesa do Safe Boot contra rootkits e similares. Embora os rootkits “script-kiddie” sejam menos comuns do que eram há uma década, os modernos rootkits de usuário, kernel e até mesmo de hipervisor rootkits ainda estão em uso ativo por criminosos e invasores de alto nível. Os rootkits continuam sendo uma das courses mais desagradáveis de malware porque se concentram na furtividade e na persistência.
Além disso: O que é Linux imutável? Veja por que você executaria uma distribuição Linux imutável
O Safe Boot é uma solução mágica? Não. Ele substitui uma boa higiene do sistema, aplicação de patches e backups? Absolutamente não. Mas o Safe Boot é um escudo significativo, e o ecossistema Linux tem trabalhado muito para torná-lo praticamente invisível para os usuários comuns. Jogar fora o Safe Boot porque hoje é uma dor é um erro.
Aqui, especificamente, está o que você deve fazer em relação aos certificados expirados.
Para seus PCs:
- Atualizar firmware: antes de meados de 2026, instale as atualizações mais recentes do BIOS/UEFI do seu fornecedor. Se fwupd suportar seu {hardware}, use-o. É menos doloroso do que fazer malabarismos com ferramentas do Home windows ou atualizadores inicializáveis.
- Confirme se a inicialização segura ainda funciona: certifique-se de que sua distribuição existente inicialize corretamente com o Safe Boot ativado. Em seguida, tente uma imagem ao vivo atual da mesma distribuição. Se ambos funcionarem, você está em boa forma.
- Mantenha a inicialização segura ativada, se puder: trate isso como uma parte regular da postura de segurança do seu sistema. Se algo falhar, depure e desative-o temporariamente conforme necessário, mas não o abandone levianamente.
Para seus servidores:
- Faça um inventário do que você tem: observe quais máquinas têm inicialização segura habilitada e qual firmware elas estão executando. Você não precisa de um banco de dados sofisticado de gerenciamento de configuração (CMDB); uma planilha está bem.
- Padronize com base em uma linha de base de firmware: escolha versões atuais de firmware que incluam as novas chaves de inicialização segura (as notas de versão do seu fornecedor podem mencionar isso) e implemente-as em seu laboratório.
- Teste novas imagens antecipadamente: antes de atualizar tudo para uma nova versão principal da distribuição, teste o instalador e a cadeia de inicialização dessa versão em um sistema representativo com inicialização segura ativada e pegue surpresas em um nó de sacrifício.
Resumindo, embora essa inicialização segura seja uma dor de cabeça, não é tão ruim assim. Apenas certifique-se de que seu firmware esteja atualizado e que sua distribuição Linux esteja pronta para lidar com os novos certificados e tudo ficará bem.
