Кризис сертификатов Secure Boot на Huawei MateBook Linux: руководство по выживанию при истечении UEFI CA в 2026 году

Дата: 30 мая 2026 г. Платформа: HUAWEI BoF-XX (MateBook M1010), 12th Gen Intel Core i7-1260P, Ubuntu Resolute Raccoon (Noble), GNOME 50.0 Статус: Platform is in Setup Mode, SecureBoot отключён, переменная db отсутствует

Аннотация

27 июня 2026 года истекает корневой сертификат Microsoft UEFI CA 2011. Для большинства пользователей Windows это лишь фоновое обновление. Для пользователей Linux на неподдерживаемом OEM-оборудовании — в частности, Huawei MateBook, отсутствующих как в Linux Vendor Firmware Service (LVFS), так и в белом списке Microsoft — это бомба замедленного действия. Статья полностью описывает техническую картину кризиса, развенчивает миф «Linux не нуждается в подписи Microsoft» и предлагает проверенный путь исправления в чистой среде Linux — для устройств, застрявших в Setup Mode без официальной поддержки производителя.

1. Анатомия истечения

1.1 Что именно умирает

Цепочка доверия Secure Boot опирается на три сертификата Microsoft, выпущенные в 2011 году:

Эти сертификаты не на диске. Они хранятся в переменных NVRAM прошивки (db, KEK, PK, dbx). После истечения срока прошивка, строго проверяющая срок действия X.509, откажется загружать любой загрузчик, подписанный только сертификатом CA 2011, — включая будущие версии Linux shim, NVIDIA GPU Option ROM и обновлённый Windows Boot Manager.

1.2 Цепочка доверия (до 2026 г.)

graph TD
    A[Платформенный ключ / PK<br/>OEM или Microsoft] -->|подписывает| B[Ключ обмена ключами / KEK<br/>Microsoft KEK CA 2011]
    B -->|подписывает| C[База подписей / db<br/>Microsoft UEFI CA 2011]
    C -->|проверяет| D[shim.efi<br/>Загрузчик Linux]
    C -->|проверяет| E[Windows Boot Manager]
    C -->|проверяет| F[NVIDIA GOP / Option ROM]
    D -->|проверяет| G[GRUB2]
    G -->|проверяет| H[Ядро Linux]
    style C fill:#ff9999,stroke:#cc0000,stroke-width:3px
    style B fill:#ff9999,stroke:#cc0000,stroke-width:3px

Рис. 1: Сертификаты 2011 года (красные) поддерживают всю цепочку сторонней загрузки. После истечения все нижележащие компоненты потеряют проверку.

1.3 Цепочка доверия (после 2026 г., идеальное состояние)

graph TD
    A[Платформенный ключ / PK] -->|подписывает| B[Ключ обмена ключами / KEK<br/>Microsoft KEK 2K CA 2023]
    B -->|подписывает| C[База подписей / db<br/>Microsoft UEFI CA 2023]
    B -->|подписывает| D[База подписей / db<br/>Windows UEFI CA 2023]
    C -->|проверяет| E[shim.efi<br/>версия с подписью 2023]
    D -->|проверяет| F[Windows Boot Manager<br/>версия с подписью 2023]
    C -->|проверяет| G[NVIDIA GOP<br/>версия с подписью 2023]
    E -->|проверяет| H[GRUB2]
    H -->|проверяет| I[Ядро 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

Рис. 2: Сертификаты 2023 года (зелёные) должны находиться в db до июня 2026 года для сохранения прямой совместимости.

2. Ловушка Huawei: отторжение экосистемой обновлений

2.1 Проблема белого списка OEM

Huawei поддерживает строгий ограниченный белый список SKU, только для которых возможна ротация сертификатов через Windows Update. Согласно официальной документации поддержки Huawei, лишь 19 конкретных SKU гарантированно получат сертификаты 2023 года через Windows Update:

• MateBook X Pro 2024 / 2022
• MateBook 14 2023 (не S)
• MateBook D16 2024
• MateStation S (определённые партии)
• …… (ещё 15 моделей)

Главный герой этой статьи — MateBook 14 2022 (BoF-XX / M1010) — явно отсутствует в списке. Это означает, что даже при установке Windows 11 запланированная задача Secure-Boot-Update скорее всего не сработает, либо прошивка отклонит запись переменной.

2.2 Отсутствие в LVFS

graph LR
    subgraph Экосистема обновлений прошивок
        A[Windows Update] -->|доставляет сертификаты| B[OEM-прошивка<br/>Dell, Lenovo, HP]
        C[LVFS / fwupd] -->|доставляет .cab| D[Linux Vendor Firmware Service]
        D -->|поддерживает| E[Dell XPS]
        D -->|поддерживает| F[Lenovo ThinkPad]
        D -->|поддерживает| G[System76]
        D -->|поддерживает| H[Framework]
        D -.->|отсутствует| I[HUAWEI MateBook]
    end
    style I fill:#ff9999,stroke:#cc0000,stroke-width:3px

Рис. 3: Huawei не публикует обновления прошивок в LVFS. Пользователи Linux не могут получить официальные обновления BIOS или сертификатов через fwupdmgr.

2.3 Заблуждение «Fedora автоматически обновила мои сертификаты»

В сообществе часто встречается возражение — «Fedora автоматически доставила обновление прошивки, Linux вообще не нужна подпись Microsoft».

Это ошибка выжившего. fwupd в Fedora работает, потому что:

1. Производитель оборудования (например, Lenovo) загрузил в LVFS обновление капсулы с новыми сертификатами.
2. Прошивка этого производителя разрешает запись переменных со стороны ОС (не все производители разрешают — HP и Fujitsu известны блокировкой записи db).
3. Модель устройства входит в матрицу поддержки производителя.

Для пользователей Huawei MateBook не выполняется ни одно из этих условий. Сертификаты находятся в NVRAM прошивки, а не в /boot/efi. Ни один дистрибутив Linux не может «волшебным образом» внедрить сертификаты, которые OEM не авторизовал и которые прошивка отказывается принимать.

3. Спасительный Setup Mode

3.1 Обнаружение золотого состояния

На Huawei MateBook M1010 автора были выполнены следующие диагностические команды:

$ 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

Ключевые находки:

• SecureBoot disabled — цепочка загрузки в настоящее время не проверяется.
• Platform is in Setup Mode — переменная PK (платформенный ключ) пуста.
• Переменная db отсутствует — база подписей не существует в NVRAM; осталась только заводская dbDefault.

3.2 Почему Setup Mode — это суперсила

В User Mode (нормальная работа) запись в db требует подписанного файла .auth. Подпись должна быть проверена существующим KEK — а закрытый ключ KEK принадлежит исключительно Microsoft. Обычный пользователь не может создать действительную подпись.

В Setup Mode (PK пуст) прошивка не применяет проверку подписи при записи переменных. Это означает, что неподписанные сырые файлы .esl (EFI Signature List) могут быть записаны непосредственно в db, KEK и PK.

stateDiagram-v2
    [*] --> SetupMode: Сброс к заводским / удаление PK
    [*] --> UserMode: Нормальная загрузка, PK зарегистрирован

    SetupMode --> UserMode: Запись PK.auth (самоподписанный)
    UserMode --> SetupMode: Удаление PK / сброс к заводским ключам

    state SetupMode {
        [*] --> db_write_unsigned
        db_write_unsigned --> [*]: efi-updatevar -f file.esl db
        note right of db_write_unsigned
            Без подписи.
            Не требуется закрытый ключ KEK.
            Прямая запись в NVRAM.
        end note
    }

    state UserMode {
        [*] --> db_write_signed
        db_write_signed --> [*]: efi-updatevar -f file.auth db
        note right of db_write_signed
            Требуется файл .auth, подписанный KEK.
            Закрытый ключ KEK только у Microsoft.
            Обычный пользователь заблокирован.
        end note
    }

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

Рис. 4: Автомат состояний доступа к переменным UEFI Secure Boot. Setup Mode (зелёный) — единственное состояние, в котором обычный пользователь может записать сертификаты без закрытого ключа Microsoft.

4. Моделирование рисков: почему «Linux не нуждается в подписи» неверно

4.1 Поверхность угроз

Пусть (R) — общий риск времени безотказной работы, разложенный как:

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

Где:

• (R_{bootkit}): вероятность заражения вредоносным ПО уровня прошивки (например, BlackLotus, CosmicStrand)
• (R_{compat}): вероятность сбоя будущих обновлений системы из-за проверки подписей
• (R_{maint}): стоимость обслуживания при ручном управлении нестандартной цепочкой загрузки

Когда Secure Boot отключён и сертификаты 2011 года истекли:

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

dbx (список отзыва) не обновляется — это означает, что известные уязвимые версии загрузчиков и shim не могут быть внесены прошивкой в чёрный список. Иммунная система системы заморожена навсегда.

4.2 Матрица рисков совместимости

Табл. 1: Матрица совместимости и безопасности. Столбец «Только сертификаты 2011» представляет состояние после июня 2026 г.

5. Исправление в чистом Linux: пошаговая инструкция

5.1 Предварительные требования

• Права root на целевой системе Linux
• Установлены пакеты efitools, openssl, uuid-runtime
• Доступ в интернет для загрузки сертификатов Microsoft 2023 года
• Резервная копия текущих переменных NVRAM (если существуют)

5.2 Этап 1: Получение сертификатов

# Создание рабочего каталога
mkdir -p ~/secureboot && cd ~/secureboot

# Загрузка Microsoft UEFI CA 2023 (формат DER)
wget -O MicUEFICA2023.der \
  "https://go.microsoft.com/fwlink/?linkid=2239872"

# Загрузка Windows UEFI CA 2023 (формат DER)
wget -O WinUEFICA2023.der \
  "https://go.microsoft.com/fwlink/?linkid=2239776"

# Преобразование в PEM для обработки 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 Этап 2: Генерация списков подписей EFI

# Генерация случайного GUID для владения списком подписей
uuidgen --random > guid.txt
GUID=$(cat guid.txt)

# Преобразование сертификатов в 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 Этап 3: Запись в NVRAM (Setup Mode)

Поскольку платформа находится в Setup Mode, записываем неподписанные файлы .esl напрямую. Файлы .auth с подписью не требуются.

# Первичное создание переменной db (без флага -a)
sudo efi-updatevar -f MicUEFICA2023.esl db

# Добавление второго сертификата (с флагом -a)
sudo efi-updatevar -a -f WinUEFICA2023.esl db

Проверка:

sudo mokutil --db

Ожидаемый фрагмент вывода:

[...]
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 Этап 4: Выход из Setup Mode (рекомендуется, но необязательно)

Оставлять систему в Setup Mode опасно — любая ОС или вредоносный загрузчик может изменить db. Мы сгенерируем личный платформенный ключ (PK) для переключения в User Mode, одновременно сохраняя Secure Boot отключённым.

# Генерация самоподписанного платформенного ключа
openssl req -new -x509 -newkey rsa:2048 \
  -subj "/CN=Personal MateBook PK/" \
  -keyout PK.key -out PK.pem \
  -days 3650 -nodes

# Преобразование в DER для обработки ESL
openssl x509 -in PK.pem -out PK.der -outform DER

# Генерация ESL
cert-to-efi-sig-list -g "$GUID" PK.der PK.esl

# Запись PK для выхода из Setup Mode
sudo efi-updatevar -f PK.esl PK

# Проверка смены состояния
sudo mokutil --sb-state
# Ожидается: "SecureBoot disabled" + "Platform is in User Mode"

5.6 Полная блок-схема

flowchart TD
    A[Начало: Huawei MateBook<br/>Чистая среда Linux] --> B{Проверка состояния}
    B -->|mokutil --sb-state| C[В Setup Mode?<br/>PK пуст?]
    C -->|Да| D[Загрузка сертификатов<br/>Microsoft 2023]
    C -->|Нет| E[Вход в BIOS → очистка PK<br/>→ перезагрузка в Linux]

    D --> F[Преобразование DER → PEM → ESL]
    F --> G[efi-updatevar -f cert.esl db]
    G --> H{Проверка<br/>mokutil --db}
    H -->|Сертификаты 2023 присутствуют| I[Генерация личного PK]
    H -->|Отсутствуют| J[Отладка: проверка dmesg<br/>права efivarfs]

    I --> K[efi-updatevar -f PK.esl PK]
    K --> L[Выход из Setup Mode<br/>Переход в User Mode]
    L --> M[Готово к будущему:<br/>сертификаты 2023 в db<br/>SecureBoot всё ещё отключён]

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

Рис. 5: Схема принятия решений по исправлению в чистом Linux на устройствах Huawei MateBook в Setup Mode.

6. Граничные случаи и сценарии отказов

6.1 Если efi-updatevar возвращает Permission denied

Некоторые OEM (HP, Fujitsu, а в будущем и версии прошивок Huawei) блокируют запись в NVRAM на уровне прошивки даже в Setup Mode. Если вы столкнулись с:

Error: Could not update variable: Permission denied

Альтернатива: Используйте KeyTool.efi (из пакета efitools), запустив его напрямую из EFI shell или меню загрузки. Он предоставляет графический интерфейс для регистрации сертификатов, обходя ограничения системных вызовов на уровне ОС.

6.2 Если переменная db уже существует

Если ls /sys/firmware/efi/efivars/ показывает файл db-8be4df61-93ca-11d2-aa0d-00e098032b8c (стандартный GUID глобальной переменной EFI), используйте флаг добавления:

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

6.3 Риск чёрного экрана NVIDIA GPU

Некоторые старые GPU NVIDIA (серии GTX 600/700/900 и ранние 10-й серии) имеют драйверы UEFI GOP, подписанные только Microsoft UEFI CA 2011. Если после июня 2026 года включить Secure Boot без регистрации CA 2023, эти GPU могут не инициализировать дисплей, что приведёт к чёрному экрану до перехвата управления ОС.

Смягчение: Предлагаемое решение регистрирует сертификаты 2023 года, одновременно оставляя Secure Boot отключённым. Это сохраняет будущую совместимость, не вызывая проверку Option ROM GPU при загрузке.

7. Заключение

Истечение сертификатов UEFI в 2026 году — это не проблема Windows. Это проблема якоря доверия на уровне прошивки. Для пользователей Huawei MateBook под чистым Linux отсутствие поддержки LVFS в сочетании с исключением из белого списка Microsoft создаёт настоящий обрыв поддержки.

Однако обнаружение устройства в Setup Mode превращает, казалось бы, невозможную блокировку платформы в прямую задачу записи в NVRAM. Сертификаты 2023 года можно зарегистрировать в чистой среде Linux, без Windows, без закрытого ключа Microsoft, без fwupd, напрямую используя efitools.

«Linux не нуждается в подписи Microsoft» — технически верно для сегодняшней загрузки, но катастрофически ошибочно для завтрашнего обслуживания. Зарегистрируйте сертификаты 2023 года сейчас — это страховка для будущих обновлений shim, прошивок GPU и сценариев двойной загрузки, которые иначе незаметно выйдут из строя, полагаясь только на якорь доверия 2011 года.

Приложение A: Команды быстрого доступа

# Проверка текущего состояния
sudo mokutil --sb-state
sudo mokutil --db | grep -i "2023"
ls /sys/firmware/efi/efivars/ | grep -i db

# Загрузка и преобразование
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

# Генерация и запись
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

Приложение B: Глоссарий

Версия документа: 1.0.0
Протестировано на: HUAWEI BoF-XX (M1010), Ubuntu Resolute Raccoon, kernel 7.0.0-12-generic