Crise do certificado de inicialização segura do Huawei MateBook Linux: o guia de sobrevivência de expiração da CA UEFI 2026

Data: 30 de maio de 2026 Plataforma: HUAWEI BoF-XX (MateBook M1010), Intel Core i7-1260P de 12ª geração, Ubuntu Resolute Raccoon (Noble), GNOME 50.0 Status: Platform is in Setup Mode, SecureBoot desativado, 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 do Windows, esta é apenas uma atualização em segundo plano. Para usuários de Linux em hardware OEM não suportado – especificamente Huawei MateBooks que estão fora do Linux Vendor Firmware Service (LVFS) e da lista de permissões da Microsoft – esta é uma bomba de contagem regressiva. Este artigo é uma dissecação técnica completa da crise, desmascara o mito de que “o Linux não precisa de assinaturas da Microsoft” e fornece um caminho de remediação do Linux puro testado em batalha – para dispositivos presos no Modo de Configuração sem nenhum canal de suporte oficial do fornecedor disponível.

1. Anatomia do Vencimento

1.1 O que realmente morre

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 a expiração, o firmware que valida estritamente os períodos de validade do X.509 se recusará a carregar qualquer bootloader assinado apenas pela CA de 2011 – incluindo futuros shim do Linux, ROMs de opção de GPU NVIDIA e gerenciador de inicialização do Windows atualizado.

1.2 Cadeia de confiança (pré-2026)

graph TD
    A[Platform Key / PK
OEM or Microsoft] -->|signs| B[Key Exchange Key / KEK
Microsoft KEK CA 2011]
    B -->|signs| C[Signature Database / db
Microsoft UEFI CA 2011]
    C -->|validates| D[shim.efi
Linux Bootloader]
    C -->|validates| E[Windows Boot Manager]
    C -->|validates| F[NVIDIA GOP / Option ROM]
    D -->|validates| G[GRUB2]
    G -->|validates| H[Linux Kernel]
    style C fill:#ff9999,stroke:#cc0000,stroke-width:3px
    style B fill:#ff9999,stroke:#cc0000,stroke-width:3px

Figura 1: Os certificados de 2011 (vermelhos) sustentam toda a cadeia de inicialização de terceiros. Após a expiração, todos os componentes downstream perdem a validação.

1.3 Cadeia de confiança (pós-2026, estado ideal)

graph TD
    A[Platform Key / PK] -->|signs| B[Key Exchange Key / KEK
Microsoft KEK 2K CA 2023]
    B -->|signs| C[Signature Database / db
Microsoft UEFI CA 2023]
    B -->|signs| D[Signature Database / db
Windows UEFI CA 2023]
    C -->|validates| E[shim.efi
2023 Signed]
    D -->|validates| F[Windows Boot Manager
2023 Signed]
    C -->|validates| G[NVIDIA GOP
2023 Signed]
    E -->|validates| H[GRUB2]
    H -->|validates| I[Linux Kernel]
    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: Os certificados 2023 (verdes) devem estar presentes em db antes de junho de 2026 para manter a compatibilidade futura.

2. A armadilha da Huawei: abandonada pelo ecossistema de atualização

2.1 O problema da lista de permissões do OEM

A Huawei mantém uma lista de permissões de SKU restrita e limitada – apenas esses modelos podem ter certificados alternados por meio do Windows Update. De acordo com a documentação oficial de suporte da Huawei, apenas 19 SKUs específicos têm garantia de recebimento dos certificados 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)

O assunto deste artigo – MateBook 14 2022 (BoF-XX / M1010) – está visivelmente ausente da lista. Isso significa que mesmo com o Windows 11 instalado, a tarefa agendada Secure-Boot-Update provavelmente não será acionada ou o firmware rejeitará as gravações de variáveis.

2.2 Lacuna LVFS

graph LR
    subgraph Vendor Firmware Update Ecosystem
        A[Windows Update] -->|pushes certs| B[OEM Firmware
Dell, Lenovo, HP]
        C[LVFS / fwupd] -->|pushes .cab| D[Linux Vendor Firmware Service]
        D -->|supports| E[Dell XPS]
        D -->|supports| F[Lenovo ThinkPad]
        D -->|supports| G[System76]
        D -->|supports| H[Framework]
        D -.->|missing| I[HUAWEI MateBook]
    end
    style I fill:#ff9999,stroke:#cc0000,stroke-width:3px

Figura 3: A Huawei não publica atualizações de firmware para LVFS. Os usuários do Linux não podem obter atualizações oficiais de BIOS ou certificados via fwupdmgr.

2.3 A falácia “O Fedora atualizou meus certificados automaticamente”

Uma refutação comum nas discussões da comunidade é: “O Fedora empurrou a atualização do firmware automaticamente; o Linux não precisa de assinaturas da Microsoft.”

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

1. O fornecedor de hardware (por exemplo, Lenovo) carregou uma atualização de cápsula contendo os novos certificados para o LVFS.
2. O firmware desse fornecedor permite gravações de variáveis ​​no lado do sistema operacional (nem todos permitem — HP e Fujitsu são conhecidas por bloquear gravações de db).
3. O modelo do dispositivo está na matriz de suporte do fornecedor.

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

3. Modo de configuração: a tábua de salvação

3.1 Descobrindo o Golden State

No Huawei MateBook M1010 do autor, executando os seguintes comandos de diagnóstico:

$ 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

Principais conclusões:

• SecureBoot disabled: A cadeia de inicialização não foi verificada no momento.
• Platform is in Setup Mode: A variável PK (chave da plataforma) está vazia.
• db variável ausente: O banco de dados de assinatura não existe na NVRAM — apenas o dbDefault padrão de fábrica permanece.

3.2 Por que o modo de configuração é uma superpotência

No Modo de usuário (operação normal), gravar em db requer arquivos .auth assinados. A assinatura deve ser verificável pelo KEK existente — e a chave privada KEK é mantida exclusivamente pela Microsoft. Usuários individuais não podem gerar assinaturas válidas.No Modo de configuração (PK está vazio), o firmware não impõe verificação de assinatura para gravações de variáveis. Isso significa que arquivos brutos não assinados .esl (Lista de Assinaturas EFI) podem ser gravados diretamente em db, KEK e PK.

stateDiagram-v2
    [*] --> SetupMode: Factory reset / PK cleared
    [*] --> UserMode: Normal boot, PK registered

    SetupMode --> UserMode: Write PK.auth (self-signed)
    UserMode --> SetupMode: Delete PK / factory reset keys

    state SetupMode {
        [*] --> db_write_unsigned
        db_write_unsigned --> [*]: efi-updatevar -f file.esl db
        note right of db_write_unsigned
            No signature required.
            No KEK private key needed.
            Direct NVRAM write.
        end note
    }

    state UserMode {
        [*] --> db_write_signed
        db_write_signed --> [*]: efi-updatevar -f file.auth db
        note right of db_write_signed
            Requires KEK-signed .auth file.
            KEK private key is Microsoft-only.
            Blocked for individuals.
        end note
    }

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

Figura 4: Máquina de estado de acesso variável UEFI Secure Boot. O Modo de Configuração (verde) é o único estado em que usuários individuais podem gravar certificados sem a chave privada da Microsoft.

4. Modelagem de risco: Por que “Linux não precisa de assinaturas” está errado

4.1 Superfície de ameaça

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

[ R = R_{bootkit} + R_{compat} + R_{manutenção} ]

Onde:

• (R_{bootkit}): Probabilidade de infecção por malware no nível do firmware (por exemplo, BlackLotus, CosmicStrand)
• (R_{compat}): Probabilidade de futuras falhas de atualização do sistema devido à validação de assinatura
• (R_{maint}): sobrecarga de manutenção do gerenciamento de uma cadeia de inicialização não padrão

Com a inicialização segura desativada e os certificados de 2011 expirados:

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

Uma dbx obsoleta (lista de revogação) significa que versões de bootloader e shim conhecidas e vulneráveis não podem ser colocadas na lista negra do firmware. O sistema imunológico do sistema está permanentemente congelado.

4.2 Matriz de risco de compatibilidade

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

5. Correção pura do Linux: passo a passo

5.1 Pré-requisitos

• Acesso root no sistema Linux de destino
• efitools, openssl, uuid-runtime instalado
• Acesso à rede para baixar certificados 2023 da Microsoft
• Backup das variáveis NVRAM atuais (se houver)

5.2 Fase 1: Obter os Certificados

# Create working directory
mkdir -p ~/secureboot && cd ~/secureboot

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

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

# Convert to PEM for efitools processing
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 assinaturas EFI

# Generate random GUID for signature list ownership
uuidgen --random > guid.txt
GUID=$(cat guid.txt)

# Convert certificates to 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 em NVRAM (modo de configuração)

Como a plataforma está no modo de configuração, grave arquivos .esl não assinados diretamente. Nenhuma assinatura .auth necessária.

# Create db variable for the first time (no -a flag)
sudo efi-updatevar -f MicUEFICA2023.esl db

# Append the second certificate (-a flag)
sudo efi-updatevar -a -f WinUEFICA2023.esl db

Verificação:

sudo mokutil --db

Snippet de saída esperado:

[...]
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 modo de configuração (recomendado, mas opcional)

Deixar o sistema no modo de configuração é perigoso — qualquer sistema operacional ou bootloader malicioso pode modificar db. Geraremos uma chave de plataforma (PK) pessoal para alternar para o modo de usuário enquanto mantemos a inicialização segura desativada.

# Generate self-signed platform key
openssl req -new -x509 -newkey rsa:2048 \
  -subj "/CN=Personal MateBook PK/" \
  -keyout PK.key -out PK.pem \
  -days 3650 -nodes

# Convert to DER for ESL processing
openssl x509 -in PK.pem -out PK.der -outform DER

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

# Write PK to exit Setup Mode
sudo efi-updatevar -f PK.esl PK

# Verify state transition
sudo mokutil --sb-state
# Expected: "SecureBoot disabled" + "Platform is in User Mode"

5.6 Fluxograma Completo

flowchart TD
    A[Start: Huawei MateBook
Pure Linux Environment] --> B{Check Status}
    B -->|mokutil --sb-state| C[In Setup Mode?
PK Empty?]
    C -->|Yes| D[Download Microsoft
2023 Certificates]
    C -->|No| E[Enter BIOS → Clear PK
→ Reboot into Linux]

    D --> F[Convert DER → PEM → ESL]
    F --> G[efi-updatevar -f cert.esl db]
    G --> H{Verify
mokutil --db}
    H -->|2023 Certificate Present| I[Generate Personal PK]
    H -->|Missing| J[Debug: Check dmesg
efivarfs Permissions]

    I --> K[efi-updatevar -f PK.esl PK]
    K --> L[Exit Setup Mode
Enter User Mode]
    L --> M[Future-Proof:
2023 Certs in db
SecureBoot Still Off]

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

Figura 5: Fluxo de decisão de correção do Linux puro para dispositivos Huawei MateBook no modo de configuração.

6. Casos extremos e modos de falha

6.1 Se efi-updatevar retornar Permission denied

Alguns OEMs (HP, Fujitsu e potencialmente futuras revisões de firmware da Huawei) bloqueiam gravações de NVRAM no nível do firmware, mesmo no modo de configuração. Se você encontrar:

Error: Could not update variable: Permission denied

Solução alternativa: Use KeyTool.efi (do pacote efitools), iniciado diretamente do shell EFI ou do menu de inicialização. Ele fornece um fluxo de trabalho gráfico de registro de certificado que ignora as restrições de syscall no nível do sistema operacional.

6.2 Se a variável db já existir

Se ls /sys/firmware/efi/efivars/ mostrar um arquivo db-8be4df61-93ca-11d2-aa0d-00e098032b8c (GUID de variável global EFI padrão), use o sinalizador append para 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 da GPU NVIDIA

Algumas GPUs NVIDIA mais antigas (série GTX 600/700/900 e início da série 10) são fornecidas com drivers UEFI GOP assinados apenas por Microsoft UEFI CA 2011. Se a inicialização segura estiver ativada após junho de 2026 sem a CA 2023 registrada, essas GPUs poderão falhar ao inicializar a exibição, resultando em uma tela preta antes que o sistema operacional assuma o controle.

Mitigação: a abordagem neste artigo registra os certificados 2023 enquanto mantém a inicialização segura desabilitada. Isso preserva a compatibilidade futura sem acionar a validação da ROM da opção GPU no momento da inicialização.

7. Conclusão

A expiração do certificado UEFI 2026 não é um problema do Windows — é um problema de âncora de confiança no nível do firmware. Para usuários do Huawei MateBook executando Linux puro, a combinação de não suporte LVFS e exclusão da lista de permissões da Microsoft cria um verdadeiro abismo de manutenção.Mas descobrir que o dispositivo estava preso no Modo de configuração transforma o que parecia ser um cenário impossível de bloqueio de plataforma em um problema direto de injeção de NVRAM. Os certificados 2023 podem ser registrados nativamente usando efitools em um ambiente Linux puro — sem Windows, sem chave privada da Microsoft, sem necessidade de fwupd.

**“Linux não precisa de assinaturas da Microsoft” é tecnicamente verdadeiro para a inicialização de hoje, mas catastroficamente errado para a manutenção de amanhã. ** Registrar os certificados de 2023 agora é uma garantia para futuras atualizações de correção, firmware de GPU e cenários de inicialização dupla - todos os quais serão quebrados silenciosamente quando apenas a âncora de confiança de 2011 permanecer.

Apêndice A: Comandos de referência rápida

# Check current status
sudo mokutil --sb-state
sudo mokutil --db | grep -i "2023"
ls /sys/firmware/efi/efivars/ | grep -i db

# Download and convert
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

# Generate and write
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
Testado em: HUAWEI BoF-XX (M1010), Ubuntu Resolute Raccoon, kernel 7.0.0-12-generic