Crise do Certificado Secure Boot em Huawei MateBook Linux: Guia de Sobrevivência para o Vencimento do CA UEFI 2026

Data: 30 de maio de 2026 Plataforma: HUAWEI BoF-XX (MateBook M1010), 12ª Geração Intel Core i7-1260P, Ubuntu Resolute Raccoon (Noble), GNOME 50.0 Status: Platform is in Setup Mode, SecureBoot desabilitado, variável db ausente

Resumo

Em 27 de junho de 2026, o certificado raiz Microsoft UEFI CA 2011 expirará. Para a maioria dos usuários Windows, isso é apenas uma atualização em segundo plano. Para usuários Linux com hardware OEM não suportado — especialmente os Huawei MateBook que não estão no Linux Vendor Firmware Service (LVFS) nem na whitelist da Microsoft — isso é uma bomba-relógio. Este artigo documenta o panorama técnico completo da crise, desmonta o mito de que “Linux não precisa de assinatura Microsoft” e oferece um caminho de reparo comprovado em ambiente puramente Linux — adequado para dispositivos presos em Setup Mode, sem canais oficiais de suporte do fabricante.

1. Anatomia do Vencimento

1.1 O Que Realmente Expira

A cadeia de confiança do Secure Boot depende de três certificados emitidos pela Microsoft em 2011:

Esses certificados não estão no disco. Eles residem nas variáveis NVRAM do firmware da placa-mãe (db, KEK, PK, dbx). Após o vencimento, firmwares que validam rigorosamente a validade X.509 se recusarão a carregar qualquer bootloader assinado apenas pelo CA 2011 — incluindo futuros shims Linux, Option ROMs de GPU NVIDIA e versões atualizadas do Windows Boot Manager.

1.2 Cadeia de Confiança (Antes de 2026)

graph TD
    A[Chave da Plataforma / PK<br/>OEM ou Microsoft] -->|assina| B[Chave de Troca de Chaves / KEK<br/>Microsoft KEK CA 2011]
    B -->|assina| C[Banco de Dados de Assinaturas / db<br/>Microsoft UEFI CA 2011]
    C -->|verifica| D[shim.efi<br/>Bootloader Linux]
    C -->|verifica| E[Windows Boot Manager]
    C -->|verifica| F[GOP NVIDIA / Option ROM]
    D -->|verifica| G[GRUB2]
    G -->|verifica| H[Kernel Linux]
    style C fill:#ff9999,stroke:#cc0000,stroke-width:3px
    style B fill:#ff9999,stroke:#cc0000,stroke-width:3px

Figura 1: Certificados de 2011 (em vermelho) sustentam toda a cadeia de inicialização de terceiros. Após o vencimento, todos os componentes downstream perderão a validação.

1.3 Cadeia de Confiança (Após 2026, Estado Ideal)

graph TD
    A[Chave da Plataforma / PK] -->|assina| B[Chave de Troca de Chaves / KEK<br/>Microsoft KEK 2K CA 2023]
    B -->|assina| C[Banco de Dados de Assinaturas / db<br/>Microsoft UEFI CA 2023]
    B -->|assina| D[Banco de Dados de Assinaturas / db<br/>Windows UEFI CA 2023]
    C -->|verifica| E[shim.efi<br/>Versão assinada 2023]
    D -->|verifica| F[Windows Boot Manager<br/>Versão assinada 2023]
    C -->|verifica| G[GOP NVIDIA<br/>Versão assinada 2023]
    E -->|verifica| H[GRUB2]
    H -->|verifica| I[Kernel Linux]
    style C fill:#99ff99,stroke:#009900,stroke-width:3px
    style D fill:#99ff99,stroke:#009900,stroke-width:3px
    style B fill:#99ff99,stroke:#009900,stroke-width:3px

Figura 2: Certificados de 2023 (em verde) devem estar presentes no db antes de junho de 2026 para manter a compatibilidade futura.

2. A Armadilha Huawei: Abandonado pelo Ecossistema de Atualizações

2.1 O Problema da Whitelist OEM

A Huawei mantém uma whitelist estrita e limitada de SKUs que podem receber a rotação de certificados via Windows Update. De acordo com o documento de suporte oficial da Huawei, apenas 19 SKUs específicos têm garantia de receber os certificados de 2023 via Windows Update:

• MateBook X Pro 2024 / 2022
• MateBook 14 2023 (não S)
• MateBook D16 2024
• MateStation S (lotes específicos)
• …… (outros 15 modelos)

O protagonista deste artigo, o MateBook 14 2022 (BoF-XX / M1010), está claramente fora da lista. Isso significa que mesmo com Windows 11 instalado, a tarefa agendada Secure-Boot-Update provavelmente não será acionada, ou o firmware rejeitará a gravação das variáveis.

2.2 Ausência no LVFS

graph LR
    subgraph Ecossistema de Atualização de Firmware
        A[Windows Update] -->|envia certificado| B[Firmware OEM<br/>Dell, Lenovo, HP]
        C[LVFS / fwupd] -->|envia .cab| D[Linux Vendor Firmware Service]
        D -->|suporta| E[Dell XPS]
        D -->|suporta| F[Lenovo ThinkPad]
        D -->|suporta| G[System76]
        D -->|suporta| H[Framework]
        D -.->|ausente| I[HUAWEI MateBook]
    end
    style I fill:#ff9999,stroke:#cc0000,stroke-width:3px

Figura 3: A Huawei não publica atualizações de firmware no LVFS. Usuários Linux não conseguem obter atualizações oficiais de BIOS ou certificados via fwupdmgr.

2.3 A Falácia do “Fedora Atualizou Meus Certificados Automaticamente”

É comum encontrar uma objeção nas discussões da comunidade — “O Fedora enviou a atualização de firmware automaticamente, Linux não precisa de assinatura Microsoft”.

Isso é viés de sobrevivência. O fwupd do Fedora funciona porque:

1. O fabricante do hardware (ex.: Lenovo) enviou uma atualização capsule contendo os novos certificados para o LVFS.
2. O firmware do fabricante permite que o sistema operacional grave variáveis (nem todos permitem — HP e Fujitsu são conhecidos por bloquear gravações em db).
3. O modelo do dispositivo está na matriz de suporte do fabricante.

Para usuários de Huawei MateBook, nenhuma das condições acima é atendida. Os certificados estão na NVRAM do firmware, não em /boot/efi. Nenhuma distribuição Linux pode “magicamente” injetar certificados que o OEM não autorizou e que o firmware se recusa a aceitar.

3. A Tábua de Salvação do Setup Mode

3.1 Descobrindo o Estado Dourado

No Huawei MateBook M1010 do autor, os comandos de diagnóstico a seguir foram executados:

$ sudo mokutil --sb-state
SecureBoot disabled
Platform is in Setup Mode

$ ls /sys/firmware/efi/efivars/ | grep -i db
dbDefault-8be4df61-93ca-11d2-aa0d-00e098032b8c
dbx-d719b2cb-3d3a-4596-a3bc-dad00e67656f
dbxDefault-8be4df61-93ca-11d2-aa0d-00e098032b8c

Descobertas críticas:

• SecureBoot disabled: A cadeia de inicialização atualmente não é validada.
• Platform is in Setup Mode: A variável PK (Chave da Plataforma) está vazia.
• Variável db ausente: O banco de dados de assinaturas não existe na NVRAM — apenas o dbDefault de fábrica permanece.

3.2 Por que o Setup Mode é um Superpoder

No User Mode (operação normal), gravar no db exige arquivos .auth assinados. A assinatura deve ser validada pela KEK existente — e a chave privada da KEK é de posse exclusiva da Microsoft. Um usuário comum não consegue gerar assinaturas válidas.

No Setup Mode (PK vazio), o firmware não impõe a validação de assinatura para gravação de variáveis. Isso significa que arquivos .esl (EFI Signature List) brutos e não assinados podem ser gravados diretamente em db, KEK e PK.

stateDiagram-v2
    [*] --> SetupMode: Restauração de fábrica / PK limpo
    [*] --> UserMode: Inicialização normal, PK registrado

    SetupMode --> UserMode: Gravar PK.auth (autoassinado)
    UserMode --> SetupMode: Excluir PK / restaurar chaves de fábrica

    state SetupMode {
        [*] --> db_write_unsigned
        db_write_unsigned --> [*]: efi-updatevar -f arquivo.esl db
        note right of db_write_unsigned
            Sem necessidade de assinatura.
            Sem necessidade de chave privada KEK.
            Gravação direta na NVRAM.
        end note
    }

    state UserMode {
        [*] --> db_write_signed
        db_write_signed --> [*]: efi-updatevar -f arquivo.auth db
        note right of db_write_signed
            Requer arquivo .auth assinado pela KEK.
            Chave privada KEK só com a Microsoft.
            Usuário comum impossibilitado.
        end note
    }

    style SetupMode fill:#99ff99,stroke:#009900
    style UserMode fill:#ffcccc,stroke:#cc0000

Figura 4: Máquina de estados de acesso às variáveis do UEFI Secure Boot. O Setup Mode (verde) é o único estado em que um usuário comum pode gravar certificados sem a chave privada da Microsoft.

4. Modelagem de Risco: Por que “Linux Não Precisa de Assinatura” Está Errado

4.1 Superfície de Ameaça

Seja (R) o risco total do tempo de inicialização, decomposto como:

[ R = R_{bootkit} + R_{compat} + R_{maint} ]

Onde:

• (R_{bootkit}): Probabilidade de infecção por malware em nível de firmware (ex.: BlackLotus, CosmicStrand)
• (R_{compat}): Probabilidade de falha em atualizações futuras do sistema devido à validação de assinatura
• (R_{maint}): Custo de manutenção do gerenciamento manual de uma cadeia de inicialização não padronizada

Quando o Secure Boot está desligado e os certificados de 2011 expiraram:

[ R_{bootkit}^{(post)} = R_{bootkit}^{(pre)} \times \delta^{-1}, \quad \delta \in (0,1) ]

O dbx (lista de revogação) não atualizado significa que bootloaders e versões de shim com vulnerabilidades conhecidas não podem ser colocados na lista negra pelo firmware. O sistema imunológico fica permanentemente congelado.

4.2 Matriz de Risco de Compatibilidade

Tabela 1: Matriz de compatibilidade e segurança. A coluna “Apenas Certificado 2011” representa o estado encalhado após junho de 2026.

5. Reparo Puramente Linux: Passo a Passo

5.1 Pré-requisitos

• Acesso root ao sistema Linux alvo
• Pacotes efitools, openssl, uuid-runtime instalados
• Acesso à internet para baixar os certificados 2023 publicados pela Microsoft
• Backup das variáveis NVRAM atuais (se existirem)

5.2 Fase 1: Obter os Certificados

# Criar diretório de trabalho
mkdir -p ~/secureboot && cd ~/secureboot

# Baixar Microsoft UEFI CA 2023 (formato DER)
wget -O MicUEFICA2023.der \
  "https://go.microsoft.com/fwlink/?linkid=2239872"

# Baixar Windows UEFI CA 2023 (formato DER)
wget -O WinUEFICA2023.der \
  "https://go.microsoft.com/fwlink/?linkid=2239776"

# Converter para formato PEM para processamento com efitools
openssl x509 -in MicUEFICA2023.der -inform DER \
  -out MicUEFICA2023.pem -outform PEM

openssl x509 -in WinUEFICA2023.der -inform DER \
  -out WinUEFICA2023.pem -outform PEM

5.3 Fase 2: Gerar Listas de Assinatura EFI

# Gerar GUID aleatório para posse da lista de assinatura
uuidgen --random > guid.txt
GUID=$(cat guid.txt)

# Converter certificados para ESL (EFI Signature List)
cert-to-efi-sig-list -g "$GUID" \
  MicUEFICA2023.pem MicUEFICA2023.esl

cert-to-efi-sig-list -g "$GUID" \
  WinUEFICA2023.pem WinUEFICA2023.esl

5.4 Fase 3: Injetar na NVRAM (Setup Mode)

Como a plataforma está em Setup Mode, grave diretamente os arquivos .esl não assinados. Não são necessários arquivos .auth assinados.

# Criar a variável db pela primeira vez (sem a flag -a)
sudo efi-updatevar -f MicUEFICA2023.esl db

# Adicionar o segundo certificado (flag -a)
sudo efi-updatevar -a -f WinUEFICA2023.esl db

Verificação:

sudo mokutil --db

Saída esperada (trecho):

[...]
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            33:00:00:02:5a:76:fb:8f:76:14:44:3b:91:00:00:00:02:5a:76
        Signature Algorithm: sha384WithRSAEncryption
        Issuer: C = US, O = Microsoft Corporation, CN = Microsoft UEFI CA 2023
[...]

5.5 Fase 4: Sair do Setup Mode (Recomendado, mas Não Obrigatório)

Manter o sistema em Setup Mode é perigoso — qualquer sistema operacional ou bootloader malicioso pode modificar o db. Vamos gerar uma Chave da Plataforma (PK) pessoal para alternar para o User Mode, mantendo o Secure Boot desabilitado.

# Gerar chave de plataforma autoassinada
openssl req -new -x509 -newkey rsa:2048 \
  -subj "/CN=Chave PK Pessoal MateBook/" \
  -keyout PK.key -out PK.pem \
  -days 3650 -nodes

# Converter para DER para processamento ESL
openssl x509 -in PK.pem -out PK.der -outform DER

# Gerar ESL
cert-to-efi-sig-list -g "$GUID" PK.der PK.esl

# Gravar PK para sair do Setup Mode
sudo efi-updatevar -f PK.esl PK

# Verificar a transição de estado
sudo mokutil --sb-state
# Esperado: "SecureBoot disabled" + "Platform is in User Mode"

5.6 Fluxograma Completo

flowchart TD
    A[Início: Huawei MateBook<br/>Ambiente puramente Linux] --> B{Verificar estado}
    B -->|mokutil --sb-state| C[Está em Setup Mode?<br/>PK vazio?]
    C -->|Sim| D[Baixar certificados<br/>Microsoft 2023]
    C -->|Não| E[Ir ao BIOS → limpar PK<br/>→ reiniciar para Linux]

    D --> F[Converter DER → PEM → ESL]
    F --> G[efi-updatevar -f cert.esl db]
    G --> H{Verificar<br/>mokutil --db}
    H -->|Certificado 2023 presente| I[Gerar PK pessoal]
    H -->|Ausente| J[Depurar: verificar dmesg<br/>permissões efivarfs]

    I --> K[efi-updatevar -f PK.esl PK]
    K --> L[Sair do Setup Mode<br/>Entrar no User Mode]
    L --> M[Preparado para o futuro:<br/>db com certificado 2023<br/>SecureBoot ainda desligado]

    style C fill:#99ff99,stroke:#009900
    style H fill:#ffcc66,stroke:#cc9900
    style M fill:#99ff99,stroke:#009900

Figura 5: Fluxo de decisão do reparo puramente Linux em dispositivos Huawei MateBook em Setup Mode.

6. Casos Limítrofes e Modos de Falha

6.1 Se efi-updatevar Retornar Permission denied

Alguns OEMs (HP, Fujitsu, e possivelmente versões futuras do firmware Huawei) bloqueiam gravações na NVRAM em nível de firmware, mesmo em Setup Mode. Se ocorrer:

Error: Could not update variable: Permission denied

Alternativa: Use o KeyTool.efi (do pacote efitools), executado diretamente do EFI shell ou do menu de inicialização. Ele oferece uma interface gráfica para o processo de registro de certificados, contornando as limitações de chamadas de sistema em nível de SO.

6.2 Se a Variável db Já Existir

Se ls /sys/firmware/efi/efivars/ mostrar o arquivo db-8be4df61-93ca-11d2-aa0d-00e098032b8c (GUID padrão de variável global EFI), use a flag de adição em todas as gravações:

sudo efi-updatevar -a -f MicUEFICA2023.esl db
sudo efi-updatevar -a -f WinUEFICA2023.esl db

6.3 Risco de Tela Preta com GPU NVIDIA

Algumas GPUs NVIDIA mais antigas (séries GTX 600/700/900 e séries 10 iniciais) possuem drivers GOP UEFI assinados apenas pelo Microsoft UEFI CA 2011. Se o Secure Boot for ativado após junho de 2026 sem o registro do CA 2023, essas GPUs podem não conseguir inicializar o monitor, resultando em tela preta antes da inicialização do sistema operacional.

Mitigação: O esquema deste artigo registra os certificados de 2023 mantendo o Secure Boot desabilitado. Isso preserva a compatibilidade futura sem acionar a validação de Option ROM de GPU durante a inicialização.

7. Conclusão

O vencimento dos certificados UEFI de 2026 não é um problema do Windows — é um problema de âncora de confiança em nível de firmware. Para usuários de Huawei MateBook rodando Linux puro, a falta de suporte no LVFS combinada com a exclusão da whitelist da Microsoft cria um verdadeiro precipício de manutenção.

Mas descobrir que o dispositivo estava encalhado em Setup Mode transformou um cenário aparentemente impossível de bloqueio de plataforma em um problema direto de injeção em NVRAM. Os certificados de 2023 podem ser registrados nativamente em ambiente puramente Linux, sem usar Windows, sem precisar da chave privada da Microsoft, sem depender do fwupd, usando apenas efitools.

“Linux não precisa de assinatura Microsoft” é tecnicamente verdadeiro para a inicialização de hoje, mas catastróficamente errado para a manutenção de amanhã. Registrar os certificados de 2023 agora é um seguro contra falhas silenciosas em futuras atualizações do shim, firmware de GPU e cenários de dual boot — todos os quais falharão se apenas a âncora de confiança de 2011 estiver presente.

Apêndice A: Comandos de Referência Rápida

# Verificar estado atual
sudo mokutil --sb-state
sudo mokutil --db | grep -i "2023"
ls /sys/firmware/efi/efivars/ | grep -i db

# Baixar e converter
wget https://go.microsoft.com/fwlink/?linkid=2239872 -O MicUEFICA2023.der
wget https://go.microsoft.com/fwlink/?linkid=2239776 -O WinUEFICA2023.der
openssl x509 -in MicUEFICA2023.der -inform DER -out MicUEFICA2023.pem -outform PEM
openssl x509 -in WinUEFICA2023.der -inform DER -out WinUEFICA2023.pem -outform PEM

# Gerar e gravar
uuidgen --random > guid.txt
cert-to-efi-sig-list -g "$(cat guid.txt)" MicUEFICA2023.pem MicUEFICA2023.esl
cert-to-efi-sig-list -g "$(cat guid.txt)" WinUEFICA2023.pem WinUEFICA2023.esl
sudo efi-updatevar -f MicUEFICA2023.esl db
sudo efi-updatevar -a -f WinUEFICA2023.esl db

Apêndice B: Glossário

Versão do documento: 1.0.0
Plataforma testada: HUAWEI BoF-XX (M1010), Ubuntu Resolute Raccoon, kernel 7.0.0-12-generic