---
title: Настройка Secure Boot
description: Настройте безопасную загрузку с помощью sbctl после установки CachyOS
tableOfContents:
  minHeadingLevel: 1
  maxHeadingLevel: 4
ai_translated: true
---

import ImageComponent from '~/components/image-component.astro';
import { Tabs, TabItem, Steps } from '@astrojs/starlight/components';

## Предварительная настройка

### Загрузчик GRUB

Если вы используете GRUB, выполните следующую команду, чтобы включить поддержку Secure Boot в GRUB с использованием CA-ключей.

```bash
sudo grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=cachyos --modules="tpm" --disable-shim-lock
```

:::note
Загрузка ненужных модулей в вашем загрузчике может представлять угрозу безопасности.
Выполняйте эту команду только в том случае, если вам действительно нужна безопасная загрузка.
:::

### Вход в режим настройки (Setup Mode) в UEFI

Сначала нам нужно зайти в настройки прошивки и установить для режима Secure Boot значение "Setup Mode" (Режим настройки). Вы можете перезагрузиться из
уже запущенной системы в настройки прошивки с помощью следующей команды.

```bash
systemctl reboot --firmware-setup
```

<br />
<ImageComponent imgsrc={import('~/assets/images/ideapad-bios-secure-boot.jpg')} />

Так выглядит BIOS на Lenovo Ideapad 5 Pro. Сбросьте в режим настройки или восстановите заводские ключи и перезагрузитесь обратно
в систему.

#### Автоматический сброс

На некоторых материнских платах Gigabyte «reset to setup mode» сразу сопровождается диалогом «reset without saving»
<ImageComponent imgsrc={import('~/assets/images/gigabyte-reset-without-saving.jpg')} />
его нужно отклонить, так как это вызовет сброс системы и отключит режим настройки.

Вместо этого загрузитесь напрямую в ОС (Save & Exit, и выберите ваш загрузчик в Boot Override).

#### Отсутствие режима настройки

На некоторых материнских платах MSI и ASUS нет режима Setup Mode.

##### MSI

Установите для Secure Boot Mode значение «custom» и выберите опцию совместимости «maximum security» (это важно: в режиме по умолчанию вы, возможно, не сможете загрузиться с вашего загрузчика в CachyOS!). Затем перейдите в «key management» и следуйте двум шагам, показанным на изображении ниже:
<br />
<ImageComponent imgsrc={import('~/assets/images/MSI-bios-secure-boot.jpg')} />

##### ASUS

перейдите в Boot → Secure Boot, установите для Secure Boot Mode значение Custom, затем откройте Key Management и выберите «Delete all Secure Boot Variables».

#### Установка sbctl и регистрация ключей

Прежде чем продолжить, убедитесь, что `sbctl` установлен.

[sbctl](https://github.com/Foxboron/sbctl) — это удобный менеджер ключей Secure Boot, способный настраивать безопасную загрузку,
предоставляющий возможности управления ключами и отслеживающий файлы, которые необходимо подписывать в цепочке загрузки.

<details>
    <summary>Как установить sbctl</summary>
    ```bash title='Откройте терминал и выполните следующую команду'
    sudo pacman -S sbctl
    ```
</details>

Теперь, когда `sbctl` установлен, необходимо его настроить и зарегистрировать ваши ключи в прошивке. Этот процесс довольно прост — просто следуйте шагам ниже.

<Steps>
1. Проверьте, включён ли режим настройки:
    ```bash
    sudo sbctl status
    ```
    <details>
        <summary>Ожидаемый вывод</summary>
        ```bash
        Installed:      ✘ sbctl is not installed
        Setup Mode:     ✘ Enabled
        Secure Boot     ✘ Disabled
        ```
    </details>
2. Создайте свои собственные ключи Secure Boot:
    ```bash
    sudo sbctl create-keys
    ```
    <details>
        <summary>Пример успешного создания ключей</summary>
        ```bash
        Created Owner UUID a9fbbdb7-a05f-48d5-b63a-08c5df45ee70
        Creating secure boot keys...✔
        Secure boot keys created!
        ```
    </details>
3. Зарегистрируйте ваши ключи вместе со встроенными ключами Microsoft и прошивки OEM:
    ```bash
    sudo sbctl enroll-keys --microsoft --firmware-builtin
    ```
    <details>
        <summary>Ожидаемый вывод</summary>
        ```bash
        Enrolling keys to EFI variables...✔
        Enrolled keys to the EFI variables!
        ```
    </details>

    :::caution[Материнские платы ASUS / Gigabyte — не используйте `--firmware-builtin`]
    На некоторых материнских платах ASUS и Gigabyte использование флага `--firmware-builtin` приводит к дублированию записей
    в переменных EFI-ключей (например, `builtin-db` появляется несколько раз в `Vendor Keys`).
    При последующей активации Secure Boot в настройках UEFI плата обнаруживает эту
    несогласованную структуру ключей и выдаёт **Secure Boot Violation** до того, как
    загрузчик успевает загрузиться.

    На платах ASUS / Gigabyte используйте только `--microsoft`:

    ```bash
    sudo sbctl enroll-keys --microsoft
    ```

    Если `Vendor Keys` показывает `microsoft builtin-db builtin-db ...`, ключи необходимо
    перерегистрировать. Повторно войдите в режим Setup Mode в UEFI (удалив все ключи), затем выполните
    `sbctl enroll-keys --microsoft` снова без `--firmware-builtin`.
    :::


4. Снова проверьте статус sbctl, чтобы убедиться, что ключи зарегистрированы и режим настройки отключён:
    ```bash
    sudo sbctl status
    ```
    <details>
        <summary>Ожидаемый вывод</summary>
        ```bash
        Installed:      ✔ sbctl is installed
        Owner GUID:     a9fbbdb7-a05f-48d5-b63a-08c5df45ee70
        Setup Mode:     ✔ Disabled
        Secure Boot     ✘ Disabled
        Vendor Keys:    microsoft
        ```
    </details>

    :::note[Режим Setup Mode показывает Enabled?]
    Если `Setup Mode` показывает **Enabled**, зайдите в настройки прошивки и **временно отключите Secure Boot**.
    Загрузитесь обратно в систему, снова проверьте статус sbctl, продолжите с [Подписи образа ядра и загрузчика](#подпись-образа-ядра-и-загрузчика)
    ниже, затем перезагрузитесь и снова включите Secure Boot в настройках прошивки.
    :::
    
</Steps>

## Подпись образа ядра и загрузчика

<Tabs>
<TabItem label='Limine'>
Limine — это особый загрузчик, который позволяет проверять хеш-суммы образов ядра
и других файлов, которые Limine использует во время загрузки. Если эта функция включена, любая
ручная настройка, выполненная пользователем, например, подпись образа через
`sbctl-batch-sign`, изменит хеш-сумму соответствующих файлов, что
приведет к сбою проверки контрольной суммы Limine.

Однако подписывать эти файлы в Limine не обязательно, потому что у него есть особый
процесс загрузки, который обходит цепочку загрузки EFI (chainloading) и проверки подписей. Единственные EFI-файлы,
которые необходимо подписать — это сам Limine.

:::caution[Limine >= 11.2.0]
Начиная с версии Limine 11.2.0, политики Secure Boot **строго применяются** при активном UEFI Secure Boot:

- Контрольная сумма конфигурации BLAKE2B **должна** быть зарегистрирована в EFI-файле Limine, иначе Limine завершится с паникой: `SECURE BOOT IS ACTIVE BUT NO CONFIG CHECKSUM IS ENROLLED`
- Все пути к файлам в `limine.conf` (ядро, initramfs и т. д.) **должны** содержать хеши BLAKE2B (например, `boot():/vmlinuz-linux#<hash>`)
- Редактор конфигурации безоговорочно отключён
- Несоответствие хешей всегда вызывает панику
:::

Чтобы включить автоматическую регистрацию контрольной суммы конфигурации, установите следующее в `/etc/default/limine`:

```sh
ENABLE_ENROLL_LIMINE_CONFIG=yes
```

Перейдите к генерации хеша для изображения заставки Limine:

:::note[Для выполнения следующих шагов требуются права суперпользователя, убедитесь, что вы используете sudo или переключились на пользователя root перед тем, как продолжить.]
:::

<Steps>

1. Проверьте текущее имя и путь к изображению заставки в файле конфигурации:
    ```sh title="Откройте терминал и выполните следующую команду:"
    sudo cat /boot/limine.conf
    ```
    Вы должны увидеть строку вида:
    ```sh
    wallpaper: boot():/limine-splash.png
    ```
2. Сгенерируйте хеш BLAKE2B для изображения заставки и добавьте его к пути в файле конфигурации:
    ```sh title="Выполните следующую команду, заменив путь на найденный в предыдущем шаге:"
    sudo b2sum /boot/limine-splash.png
    ```
    Это выведет хеш, подобный следующему примеру:
    ```sh
    75205d08fa9c61599897857e861d6b2f6da25465183fc4cc9efecffb22ee630efb510f2ef1b17677db94c28d5c69ad2ceb4d3892f5bec9cfa65c97b5ba16f52f
    ```
3. После копирования сгенерированного на предыдущем шаге хеша откройте файл конфигурации в текстовом редакторе и добавьте хеш к пути изображения заставки, как здесь:
    :::note[Не используйте пример хеша из приведённого выше примера, убедитесь, что вы используете хеш, сгенерированный на предыдущем шаге.]
    :::
    ```sh
    wallpaper: boot():/limine-splash.png#75205d08fa9c61599897857e861d6b2f6da25465183fc4cc9efecffb22ee630efb510f2ef1b17677db94c28d5c69ad2ceb4d3892f5bec9cfa65c97b5ba16f52f
    ```
    Как видите, хеш добавляется к пути с символом `#`. Сохраните файл после внесения изменений.

</Steps>

После включения регистрации контрольной суммы конфигурации и генерации хеша для изображения заставки, выполните следующие команды для регистрации контрольной суммы конфигурации и подписи EFI-файла Limine:

```sh
# Используйте limine-enroll-config для регистрации контрольной суммы конфигурации и подписи EFI-файла Limine
# Это использует sbctl под капотом
sudo limine-enroll-config
sudo limine-update
```
</TabItem>
<TabItem label='systemd-boot'>

CachyOS предоставляет [sbctl-batch-sign](https://github.com/CachyOS/CachyOS-Settings/blob/master/usr/bin/sbctl-batch-sign),
скрипт, который берет список файлов, требующих подписи, из вывода `sudo sbctl verify` и подписывает их все.

:::caution
В системах с отдельными разделами `/boot` и `/boot/efi` утилита `sbctl` может сканировать исполняемые EFI-файлы только в `/boot/efi`.
Это приводит к тому, что образы ядра, находящиеся в `/boot`, не обнаруживаются. Утилита `sbctl-batch-sign` обходит эту проблему, **всегда** сканируя
`/boot` на наличие файлов `vmlinuz-*`.
:::

```bash
sudo sbctl verify
Verifying file database and EFI images in /boot...
✘ /boot/1c4b5246eef05ac3bc87339323cd5101/6.10.0-cn4.0.fc40.x86_64/linux is not signed
✘ /boot/EFI/BOOT/BOOTX64.EFI is not signed
✘ /boot/EFI/systemd/systemd-bootx64.efi is not signed
✘ /boot/1c4b5246eef05ac3bc87339323cd5101/0-rescue/linux is not signed
✘ /boot/1c4b5246eef05ac3bc87339323cd5101/6.10.0-cn3.0.fc40.x86_64/linux is not signed

sudo sbctl-batch-sign

sudo sbctl verify
Verifying file database and EFI images in /boot...
✔ /boot/1c4b5246eef05ac3bc87339323cd5101/6.10.0-cn4.0.fc40.x86_64/linux is signed
✔ /boot/EFI/BOOT/BOOTX64.EFI is signed
✔ /boot/EFI/systemd/systemd-bootx64.efi is signed
✔ /boot/1c4b5246eef05ac3bc87339323cd5101/0-rescue/linux is signed
✔ /boot/1c4b5246eef05ac3bc87339323cd5101/6.10.0-cn3.0.fc40.x86_64/linux is signed
```

Теперь, когда все файлы подписаны. **Перезагрузите систему и зайдите в настройки UEFI, чтобы включить Secure Boot.**

:::caution[Материнские платы ASUS — включение Secure Boot]
Некоторые материнские платы ASUS ведут себя иначе, чем платы других производителей, при включении Secure Boot:

- **Используйте `Windows UEFI Mode`, а не `Other OS`:**
  Название вводит в заблуждение — этот параметр просто управляет тем, применяется ли Secure Boot.
  Установка `OS Type` в `Other OS` **активно отключает** Secure Boot на платах ASUS,
  независимо от любых других настроек. `sbctl status` продолжит показывать
  `Secure Boot: Disabled` даже после перезагрузки.

- **На некоторых платах ASUS нет отдельного переключателя Secure Boot.**
  Secure Boot активируется неявно при выборе `Windows UEFI Mode`.

Правильная конфигурация BIOS ASUS для активации Secure Boot в этом случае:
```
Boot → Secure Boot
  OS Type          → Windows UEFI Mode
  Secure Boot Mode → Custom
```
:::

Обратитесь к [этому разделу для справки](/ru/configuration/secure_boot_setup#вход-в-режим-настройки-setup-mode-в-uefi)

Обратите внимание, что это одноразовый процесс, так как подпись файлов с флагом `-s` сохранит эти файлы в базе данных `sbctl`.

:::tip[Напоминание]
`sbctl` поставляется с [хуком pacman](https://wiki.archlinux.org/title/Pacman_hook), что означает, что он будет автоматически
подписывать все новые файлы при обновлении ядра или загрузчика.
:::

CachyOS использует `systemd-boot-update.service`, предоставляемый systemd, для обновления загрузчика при перезагрузке. Это означает, что хук pacman
`sbctl` **не** будет подписывать обновленные EFI-файлы. В качестве обходного пути мы можем подписать загрузчик напрямую.

```sh
sudo sbctl sign -s -o /usr/lib/systemd/boot/efi/systemd-bootx64.efi.signed /usr/lib/systemd/boot/efi/systemd-bootx64.efi
```
</TabItem>
</Tabs>

## Проверка включения Secure Boot

Чтобы убедиться, что безопасная загрузка действительно включена, вы можете выполнить одну из следующих команд:

```bash
sudo sbctl status
Installed:      ✓ sbctl is installed
Owner GUID:     a9fbbdb7-a05f-48d5-b63a-08c5df45ee70
Setup Mode:     ✓ Disabled
Secure Boot:    ✓ Enabled
Vendor Keys:    microsoft

bootctl
System:
      Firmware: UEFI 2.80 (INSYDE Corp. 28724.16435)
 Firmware Arch: x64
   Secure Boot: enabled (user)
  TPM2 Support: yes
  Measured UKI: no
  Boot into FW: supported
```

## Ссылки и благодарности

- [The Arch Wiki](https://wiki.archlinux.org/title/Unified_Extensible_Firmware_Interface/Secure_Boot#Assisted_process_with_sbctl)
заложила основу для этого руководства. Большая часть материала взята оттуда.
- [sbctl](https://github.com/Foxboron/sbctl) - Это простое руководство по включению поддержки Secure Boot не было бы возможным, если бы не
потрясающая работа по созданию этой программы.
- [Improving the Secure Boot Experience by Morten linderud](https://linderud.dev/blog/improving-the-secure-boot-user-experience/) - Статья в блоге Мортена
"Foxboron" Линдеруда о том, насколько сложным был опыт работы с безопасной загрузкой до появления `sbctl`.
