UEFI и Secure Boot в виртуалке: когда это нужно

MAATRIX

При создании виртуалки почти всегда есть выбор прошивки: классический BIOS-совместимый режим (в KVM/QEMU это SeaBIOS) или UEFI (OVMF). Разница на первый взгляд кажется чисто технической и неважной — но именно от неё зависит, установится ли Windows 11, увидит ли гипервизор диск на несколько терабайт целиком и не откажется ли грузиться конкретный дистрибутив. Разберём, когда UEFI действительно нужен, когда без него прекрасно можно жить, и что происходит, если вдобавок включить Secure Boot.

Чем UEFI отличается от BIOS на практике

BIOS (в виртуализации — SeaBIOS) — это старый стандарт прошивки, который проектировался ещё под ограничения дисков и загрузчиков 80-90-х годов. Он работает по MBR-схеме разметки диска, читает загрузочный код из первых 446 байт первого сектора и передаёт управление операционной системе почти без всякой инфраструктуры вокруг. Это просто, надёжно и десятилетиями обкатано — именно поэтому SeaBIOS до сих пор идёт в QEMU/KVM по умолчанию.

UEFI (Unified Extensible Firmware Interface) — более новый стандарт, который умеет заметно больше:

• работает с GPT-разметкой диска, где нет физического ограничения на количество разделов и на size диска в 2 ТиБ, характерного для MBR;
• хранит загрузчики как обычные файлы на отдельном служебном разделе (ESP, EFI System Partition), а не как код в загрузочном секторе;
• поддерживает Secure Boot — проверку цифровых подписей загрузчика и ядра ещё до старта ОС;
• умеет работать с сетевой загрузкой, drivers на этапе прошивки и рядом других возможностей, которые в BIOS попросту не предусмотрены архитектурно.

В виртуализации UEFI реализован проектом OVMF (Open Virtual Machine Firmware, часть tianocore) — это открытая имплементация UEFI-прошивки специально для QEMU/KVM. В Proxmox VE выбор делается в свойствах VM: Options → SeaBIOS или Options → OVMF (UEFI). При выборе OVMF Proxmox также попросит подключить отдельный маленький диск под EFI-переменные (обычно 1 MiB на ZFS/LVM, либо файл на директории) — без него настройки UEFI не переживут перезагрузку.

Важный нюанс: UEFI — это не "более современный, поэтому лучше по умолчанию". Это другой набор возможностей под другие задачи. Для классического Linux-сервера без специфичных требований разница между BIOS и UEFI на практике не ощущается никак — система одинаково быстро грузится и одинаково стабильно работает в обоих режимах.

Случай 1: Windows 11 как гостевая ОС

Самый частый и самый однозначный повод включить UEFI — установка Windows 11 в виртуалке. Microsoft заявила UEFI, Secure Boot и модуль TPM 2.0 официальными системными требованиями для Windows 11, и инсталлятор реально их проверяет на этапе установки.

Что нужно для честной установки Windows 11 в KVM/Proxmox:

Options → Machine: q35
Options → BIOS: OVMF (UEFI)
Options → Add: EFI Disk (для хранения EFI-переменных)
Options → Add: TPM State (v2.0) — виртуальный TPM-модуль
Options → Enable Secure Boot: включить в EFI Disk

Без этого набора установщик Windows 11 либо откажется ставиться с сообщением о несоответствии требованиям, либо потребует обхода официальных проверок — правки реестра в момент установки (BypassTPMCheck, BypassSecureBootCheck и подобные ключи) или использования модифицированного установочного образа. Такой обход работает, но это осознанный отход от официально поддерживаемой конфигурации: часть будущих обновлений системы теоретически может опираться на наличие TPM, и вы будете эксплуатировать систему в режиме "как получилось", а не "как задумано".

Практический вывод: если вам действительно нужна именно Windows 11 (не Windows Server и не Windows 10) — сразу закладывайте UEFI + vTPM + Secure Boot в конфигурацию VM. Это не опция для перестраховки, а обязательное системное требование конкретной ОС.

Случай 2: большие диски и GPT-разметка

Классическая MBR-разметка диска физически ограничена: адресация секторов в заголовке раздела — 32-битная, и при стандартном размере сектора в 512 байт это даёт математический предел около 2 ТиБ на диск. Диски и разделы больше этого предела MBR корректно описать не может.

GPT (GUID Partition Table) снимает это ограничение — GPT-диски поддерживают куда больший объём (на практике — многие эксабайты, вопрос упирается в реализацию ОС и контроллера, а не в формат таблицы) и до 128 разделов из коробки без танцев с расширенными разделами, как в MBR.

Здесь важно разделить два разных вопроса:

1. Может ли GPT работать с BIOS? Технически да — есть режим BIOS boot partition, который позволяет грузиться с GPT-диска в legacy-режиме. Но поддержка не универсальна, зависит от загрузчика (GRUB это умеет), и на практике вокруг этой связки регулярно вылезают нюансы конкретных дистрибутивов и версий загрузчиков.
2. Как это принято делать сейчас? UEFI изначально спроектирован для работы с GPT, и связка UEFI + GPT — это путь с наименьшим числом сюрпризов: инсталляторы современных ОС по умолчанию создают именно такую разметку, когда видят UEFI-прошивку, без ручной возни с загрузочными разделами.

Если вы планируете диск виртуалки больше 2 ТиБ (например, под файловое хранилище или базу данных с большим объёмом), разумно сразу ставить VM в режим UEFI и не связываться с GPT-под-BIOS as an edge case. Для дисков меньшего размера — это не аргумент за UEFI сам по себе, для 20-200 ГБ MBR под BIOS работает без всяких ограничений.

Случай 3: Linux-дистрибутивы с UEFI-специфичными механизмами загрузки

Часть современных Linux-дистрибутивов по умолчанию заточена под UEFI-загрузку и использует механизмы, которые в чистом виде под BIOS не существуют — например, systemd-boot как загрузчик (в отличие от GRUB, systemd-boot вообще не умеет грузиться в legacy BIOS-режиме, только через UEFI) или secure-boot-подписанные ядра, которые дистрибутив готовит из коробки под конкретные цепочки доверия.

На практике большинство серверных дистрибутивов (Ubuntu Server, Debian, AlmaLinux/Rocky) прекрасно ставятся и работают в BIOS-режиме — их установщики одинаково хорошо готовят и MBR/GRUB-legacy, и GPT/UEFI-конфигурацию, в зависимости от того, что видят у гипервизора. Проблема возникает точечно: если вы берёте образ или конфигурацию, которая явно рассчитана только на UEFI (готовый cloud-образ с systemd-boot, специфичный live-дистрибутив, инструкция из мануала конкретного проекта), — стоит на старте проверить требования этого конкретного образа, а не полагаться на то, что "Linux же всегда грузится откуда угодно".

Практический чек перед установкой — если в документации дистрибутива или образа явно упоминается systemd-boot, Secure Boot из коробки или EFI System Partition как обязательный элемент — берите OVMF сразу, не тратьте время на попытку завести это через SeaBIOS.

Когда включать Secure Boot и что это реально защищает

Secure Boot — это проверка цифровых подписей на каждом шаге цепочки загрузки: прошивка проверяет подпись загрузчика, загрузчик проверяет подпись ядра, ядро (в некоторых конфигурациях) проверяет подписи модулей. Если подпись не совпадает с доверенным ключом в базе UEFI — компонент не запускается.

Это осмысленная защита от конкретного класса угроз — буткитов и руткитов, которые встраиваются в цепочку загрузки до старта ОС и её защитных механизмов (антивируса, EDR и так далее). Такой малварь исторически было сложно обнаружить именно потому, что она стартует раньше любого защитного ПО. Secure Boot закрывает именно этот вектор: неподписанный или подписанный чужим ключом загрузочный компонент просто не запустится.

Это НЕ универсальная галочка "включить для безопасности везде". Стоит включать Secure Boot осознанно, когда:

• система обрабатывает чувствительные данные и модель угроз включает компрометацию хоста на уровне загрузки;
• это требование конкретной гостевой ОС (Windows 11, как в случае 1);
• вы соответствуете внутренним или внешним требованиям безопасности (compliance), где Secure Boot прямо упомянут как контроль.

Для рядового Linux-сервера, который крутит сайт, базу данных или пару Docker-контейнеров за обычным SSH-доступом, Secure Boot почти всегда избыточен как отдельная мера — угроза буткита требует уже состоявшегося физического или очень глубокого удалённого компрометирования хоста, и в модели угроз обычного VPS это не первая линия защиты, о которой стоит беспокоиться.

Когда Secure Boot создаёт проблемы

Обратная сторона Secure Boot — он ломает загрузку всего, что не подписано ключом из доверенной базы UEFI. На практике это чаще всего:

• Сторонние ядерные модули, собранные локально (DKMS-модули для видеокарт, специфичного сетевого оборудования, файловых систем вроде ZFS в некоторых сборках) — если модуль не подписан доверенным ключом, ядро с включённым Secure Boot откажется его загружать, и вы получите рабочую систему без нужного модуля, часто без явной ошибки в логах, пока не начнёте разбираться специально.
• Проприетарные видеодрайверы (в первую очередь NVIDIA в некоторых конфигурациях) — похожая история: неподписанный модуль ядра тихо не грузится.
• Кастомные ядра и загрузчики, собранные вручную не через официальный пакетный менеджер дистрибутива — если вы пересобираете ядро под свои нужды, при включённом Secure Boot придётся либо подписывать его собственным ключом (и добавлять этот ключ в базу доверенных ключей MOK — Machine Owner Key), либо отключать Secure Boot для этой машины.

Решение в такой ситуации — одно из двух: получить корректно подписанную версию модуля/драйвера (у многих проектов есть DKMS-хуки, которые сами регистрируют MOK-ключ при сборке — тогда достаточно один раз подтвердить его на экране MokManager при следующей загрузке), либо явно отключить Secure Boot именно для этой машины, если требование к нему не жёсткое. Второй вариант не "дыра в безопасности вообще" — если у вас нет отдельного требования на Secure Boot (см. предыдущий раздел), отключение просто возвращает вас к тому уровню защиты, на котором и так работает большинство серверов.

Как переключить режим в уже существующей VM

Смена BIOS ↔ UEFI на уже установленной и работающей системе — операция рискованная и не всегда возможная без переустановки, потому что разметка диска (MBR vs GPT) и содержимое загрузочного раздела должны соответствовать выбранному режиму прошивки. Если вы ставили систему под SeaBIOS с MBR-разметкой, простое переключение VM на OVMF в настройках Proxmox не заставит её загрузиться — прошивка попросту не найдёт EFI System Partition.

Практический путь, если действительно нужно перейти на UEFI на уже работающей машине:

1. Сделать снапшот или полный бэкап VM перед экспериментами — proxmox-backup-server или обычный snapshot средствами хранилища.
2. Для Linux — сконвертировать разметку из MBR в GPT можно инструментом gdisk (режим w в интерактивном меню mbr2gpt-конверсии) без потери данных, но с последующей переустановкой загрузчика GRUB в UEFI-режиме (grub-install --target=x86_64-efi изнутри chroot с смонтированным ESP).
3. Для Windows — есть встроенный mbr2gpt.exe начиная с Windows 10, который умеет конвертировать системный диск на лету без переустановки, при условии что диск использует схему разделов, которую утилита умеет мигрировать.
4. После конвертации диска переключить прошивку VM на OVMF, добавить EFI Disk, и только затем включать Secure Boot отдельным шагом — не пытайтесь включить всё сразу, чтобы легче было найти, что именно сломалось, если что-то не завелось.

Если такой миграции можно избежать — новую VM в правильном режиме прошивки проще создать с нуля, чем мигрировать существующую. Особенно для тестовых и легко воспроизводимых нагрузок.

Частые вопросы