Uefi secure boot что это

Содержание

Ubuntu Wiki
Supported architectures
Testing UEFI Secure Boot
How UEFI Secure Boot works on Ubuntu
How can I do non-automated signing of drivers?
Security boot fail. Acer. BIOS 100% способ решения проблемы.Помогло? Подпишись на канал)
Security implications in Machine-Owner Key management
MOK generation and signing process
- The user installs Ubuntu on a new system
- The user upgrades an UEFI-enabled Ubuntu system to a new release where the system requires third-party drivers
Переходим на UEFI вместо BIOS
- Как работает UEFI
Что такое UEFI и как он работает

Unsigned modules are simply refused by the kernel. Any attempt to insert them with insmod or modprobe will fail with an error message.

Ubuntu Wiki

UEFI Secure boot is a verification mechanism for ensuring that code launched by firmware is trusted.

Proper, secure use of UEFI Secure Boot requires that each binary loaded at boot is validated against known keys, located in firmware, that denote trusted vendors and sources for the binaries, or trusted specific binaries that can be identified via cryptographic hashing.

Most x86 hardware comes from the factory pre-loaded with Microsoft keys. This means we can generally rely on the firmware on these systems to trust binaries that are signed by Microsoft, and the Linux community heavily relies on this assumption for Secure Boot to work. This is the same process used by Red Hat and SUSE, for instance.

Many ARM and other architectures also support UEFI Secure Boot, but may not be pre-loading keys in firmware. On these architectures, it may be necessary to re-sign boot images with a certificate that is loaded in firmware by the owner of the hardware.

Initial implementation plan: Implementation Plan.

Supported architectures

amd64: A shim binary signed by Microsoft and grub binary signed by Canonical are provided in the Ubuntu main archive as shim-signed or grub-efi-amd64-signed.
arm64: As of 20.04 (‘focal’), a shim binary signed by Microsoft and grub binary signed by Canonical are provided in the Ubuntu main archive as shim-signed or grub-efi-arm64-signed. There is a GRUB bug under investigation that needs to be resolved before this works end to end.

Testing UEFI Secure Boot

If you’re interested in testing Secure Boot on your system, consult the how-to here: UEFI/SecureBoot/Testing.

How UEFI Secure Boot works on Ubuntu

On Ubuntu, all pre-built binaries intended to be loaded as part of the boot process, with the exception of the initrd image, are signed by Canonical’s UEFI certificate, which itself is implicitly trusted by being embedded in the shim loader, itself signed by Microsoft.

On architectures or systems where pre-loaded signing certificates from Microsoft are not available or loaded in firmware, users may replace the existing signatures on shim or grub and load them as they wish, verifying against their own certificates imported in the system’s firmware.

As the system boots, firmware loads the shim binary as specified in firmware BootEntry variables. Ubuntu installs its own BootEntry at installation time and may update it any time the GRUB bootloader is updated. Since the shim binary is signed by Microsoft; it is validated and accepted by the firmware when verifying against certificates already present in firmware. Since the shim binary embeds a Canonical certificate as well as its own trust database, further elements of the boot environment can, in addition to being signed by one of the acceptable certificates pre-loaded in firmware, be signed by Canonical’s UEFI key.

The next thing loaded by shim is the second-stage image. This can be one of two things: either GRUB, if the system is booting normally; or MokManager, if key management is required, as configured by firmware variables (usually changed when the system was previously running).

If booting normally; the GRUB binary (grub*.efi) is loaded and its validation is attempted against all previously-known trusted sources. The GRUB binary for Ubuntu is signed by the Canonical UEFI key, so it is successfully validated and the boot process continues.

If booting to proceed with key management tasks, the MokManager binary (mm*.efi) is loaded. This binary is explicitly trusted by shim by being signed by an ephemeral key that only exists while the shim binary is being built. This means only the MokManager binary built with a particular shim binary will be allowed to run and limits the possibility of compromise from the use of compromised tools. MokManager allows any user present at the system console to enroll keys, remove trusted keys, enroll binary hashes and toggle Secure Boot validation at the shim level, but most tasks require a previously set password to be entered to confirm that the user at console is indeed the person who requested changes. Such passwords only survive across a single run of shim / MokManager; and are cleared as soon as the process is completed or cancelled. Once key management is completed, the system is rebooted and does not simply continue with booting, since the key management changes may be required to successfully complete the boot.

Once the system continues booting to GRUB; the GRUB process loads any required configuration (usually loading configuration from the ESP (EFI System Partition), pointing to another configuration file on the root or boot partition), which will point it to the kernel image to load.

EFI applications up to this point having full access to the system firmware, including access to changing trusted firmware variables, the kernel to load must also be validated against the trust database. Official Ubuntu kernels being signed by the Canonical UEFI key, they are successfully validated, and control is handed over to the kernel. Initrd images are not validated.

In the case of unofficial kernels, or kernels built by users, additional steps need to be taken if users wish to load such kernels while retaining the full capabilities of UEFI Secure Boot. All kernels must be signed to be allowed to load by GRUB when UEFI Secure Boot is enabled, so the user will require to proceed with their own signing. Alternatively, users may wish to disable validation in shim while booted with Secure Boot enabled on an official kernel by using ‘sudo mokutil —disable-validation’, providing a password when prompted, and rebooting; or to disable Secure Boot in firmware altogether.

Up to this point, any failure to validate an image to load is met with a critical error which stops the boot process. The system will not continue booting, and may automatically reboot after a period of time given that other BootEntry variables may contain boot paths that are valid and trusted.

Once loaded, validated kernels will disable the firmware’s Boot Services, thus dropping privileges and effectively switching to user mode; where access to trusted variables is limited to read-only. Given the broad permissions afforded to kernel modules, any module not built into the kernel will also need to be validated upon loading. Modules built and shipped by Canonical with the official kernels are signed by the Canonical UEFI key and as such, are trusted. Custom-built modules will require the user to take the necessary steps to sign the modules before they loading them is allowed by the kernel. This can be achieved by using the ‘kmodsign’ command [see section].

Unsigned modules are simply refused by the kernel. Any attempt to insert them with insmod or modprobe will fail with an error message.

Given that many users require third-party modules for their systems to work properly or for some devices to function; and that these third-party modules require building locally on the system to be fitted to the running kernel, Ubuntu provides tooling to automate and simplify the signing process.

How can I do non-automated signing of drivers?

Some projects may require the use of custom kernel drivers that are not set up in such a way as to work with DKMS. In these cases, people should make use of the tools included in the shim-signed package: the update-secureboot-policy script is available to generate a new MOK (if no DKMS-built modules have triggered generating one already).

Use the following command to enroll an existing key into shim:

sudo update-secureboot-policy --enroll-key

If no MOK exists, the script will exit with a message to that effect. If the key is already enrolled, the script will exit, doing nothing. If the key exists but it not shown to be enrolled, the user will be prompted for a password to use after reboot, so that the key can be enrolled.

One can generate a new MOK using the following command:

sudo update-secureboot-policy --new-key

And then enroll the newly-generated key into shim with the previously-mentioned command for that task.

Security boot fail. Acer. BIOS 100% способ решения проблемы.Помогло? Подпишись на канал)

Kernel modules can then be signed with the kmodsign command (see UEFI/SecureBoot/Signing) as part of their build process.

Security implications in Machine-Owner Key management

The MOK generated at installation time or on upgrade is machine-specific, and only allowed by the kernel or shim to sign kernel modules, by use of a specific KeyUsage OID (1.3.6.1.4 Января 2312.16.1.2) denoting the limitations of the MOK.

Recent shim versions include logic to follow the limitations of module-signing-only keys. These keys will be allowed to be enrolled in the firmware in shim’s trust database, but will be ignored when shim or GRUB validate images to load in firmware. Shim’s verify() function will only successfully validate images signed by keys that do not include the «Module-signing only» (1.3.6.1.4 Января 2312.16.1.2) KeyUsage OID. The Ubuntu kernels use the global trust database (which includes both shim’s and the firmware’s) and will accept any of the included keys as signing keys when loading kernel modules.

Given the limitations imposed on the automatically generated MOK and the fact that users with superuser access to the system and access to the system console to enter the password required when enrolling keys already have high-level access to the system; the generated MOK key is kept on the filesystem as regular files owned by root with read-only permissions. This is deemed sufficient to limit access to the MOK for signing by malicious users or scripts, especially given that no MOK exists on the system unless it requires third-party drivers. This limits the possibility of compromise from the misuse of a generated MOK key to signing a malicious kernel module. This is equivalent to compromise of the userland applications which would already be possible with superuser access to the system, and securing this is out of the scope of UEFI Secure Boot.

Previous systems may have had Secure Boot validation disabled in shim. As part of the upgrade process, these systems will be migrated to re-enabling Secure Boot validation in shim and enrolling a new MOK key when applicable.

MOK generation and signing process

The key generation and signing process is slightly different based on whether we are dealing with a brand new installation or an upgrade of system previously running Ubuntu; these two cases are clearly marked below.

In all cases, if the system is not booting in UEFI mode, no special kernel module signing steps or key generation will happen.

If Secure Boot is disabled, MOK generation and enrollment still happens, as the user may later enable Secure Boot. They system should work properly if that is the case.

The user installs Ubuntu on a new system

The user steps through the installer. Early on, when preparing to install and only if the system requires third-party modules to work, the user is prompted for a system password that is clearly marked as being required after the install is complete, and while the system is being installed, a new MOK is automatically generated without further user interaction.

Third-party drivers or kernel modules required by the system will be automatically built when the package is installed, and the build process includes a signing step. The signing step automatically uses the MOK generated earlier to sign the module, such that it can be immediately loaded once the system is rebooted and the MOK is included in the system’s trust database.

Once the installation is complete and the system is restarted, at first boot the user is presented with the MokManager program (part of the installed shim loader), as a set of text-mode panels that all the user to enroll the generated MOK. The user selects «Enroll MOK», is shown a fingerprint of the certificate to enroll, and is prompted to confirm the enrollment. Once confirmed, the new MOK will be entered in firmware and the user will be asked to reboot the system.

When the system reboots, third-party drivers signed by the MOK just enrolled will be loaded as necessary.

The user upgrades an UEFI-enabled Ubuntu system to a new release where the system requires third-party drivers

On upgrade, the shim and shim-signed packages are upgraded. The shim-signed package’s post-install tasks proceeds to generate a new MOK, and prompts the user for a password that is clearly mentioned as being required once the upgrade process is completed and the system rebooted.

During the upgrade, the kernel packages and third-party modules are upgraded. Third-party modules are rebuilt for the new kernels and their post-build process proceeds to automatically sign them with the MOK.

After upgrade, the user is recommended to reboot their system.

On reboot, the user is presented with the MokManager program (part of the installed shim loader), as a set of text-mode panels that all the user to enroll the generated MOK. The user selects «Enroll MOK», is shown a fingerprint of the certificate to enroll, and is prompted to confirm the enrollment. The user is also presented with a prompt to re-enable Secure Boot validation (in the case it was found to be disabled); and MokManager again requires confirmation from the user. Once all steps are confirmed, shim validation is re-enabled, the new MOK will be entered in firmware and the user will be asked to reboot the system.

When the system reboots, third-party drivers signed by the MOK just enrolled will be loaded as necessary.

In all cases, once the system is running with UEFI Secure Boot enabled and a recent version of shim; the installation of any new DKMS module (third-party driver) will proceed to sign the built module with the MOK. This will happen without user interaction if a valid MOK key exists on the system and appears to already be enrolled.

If no MOK exists or the existing MOK is not enrolled, a new key will automatically created just before signing and the user will be prompted to enroll the key by providing a password which will be required upon reboot.

UEFI/SecureBoot (последним исправлял юзер dannf 8 Апреля 2020 14:07:55)

Переходим на UEFI вместо BIOS

С выходом Windows 8 производители стали активнее внедрять преемника BIOS — интерфейс UEFI, который за время собственного существования уже успел доставить много проблем. Мы поведаем как, невзирая на это, пользоваться его преимуществами. Массовый переход на UEFI (Unified Extensible Firmware Interface) уже начался. Microsoft просит использовать этот интерфейс на всех компьютерах, которые будут поставляться с Windows […]

Массовый переход на UEFI (Unified Extensible Firmware Interface) уже начался. Microsoft просит использовать этот интерфейс на всех компьютерах, которые будут поставляться с Windows 8. Поточнее говоря, идет речь об UEFI с функцией Secure Boot. При всем этом без заморочек работать на схожих ПК может только «восьмерка»: ни Windows XP, ни «семерку» не получится установить на UEFI-машину без дополнительных манипуляций.

С флеш-накопителя Linux Live либо Windows загрузиться тоже не получится. Что конкретно может произойти, если попробовать запуститься с установочной флешки на ноутбуке Sony VAIO, показано на картинке вверху. И на этом трудности с UEFI не завершаются. Каждый производитель аппаратных компонент по собственному усмотрению изменяет UEFI, тем создавая для юзера ненадобные трудности. Лэптоп IdeaPad от Lenovo и совсем не сумел распознать тот же самый флеш-накопитель в качестве загрузочного носителя. При всем этом Lenovo не в чем упрекнуть: дело в том, что загрузочная флешка отформатирована в файловой системе NTFS, а UEFI не поддерживает загрузку с таких носителей. Если подключить тот же накопитель к ноутбуку EliteBook от HP, то он загрузится без заморочек и дозволит выполнить установку Windows. Неувязка же состоит в том, что все данные, имевшиеся на диске EliteBook, после установки оказались бы удаленными.

Каждый изменяет по-своему

Вы в замешательстве? Ничего необычного: UEFI с функцией Secure Boot устанавливает новые правила установки и загрузки операционных систем, а производители аппаратных средств по-своему трактуют эти правила, что делает для юзера дополнительные трудности. Потому в рамках данной статьи мы поставили впереди себя цель убрать путаницу вокруг UEFI. На примере ноутбуков от главных производителей мы поведаем, как работает UEFI, какая роль отводится функции Secure Boot, как обойти расставляемые новым интерфейсом «ловушки» и что необходимо для того, чтоб использовать загрузочные флеш-накопители, не боясь никаких разрушительных последствий.

Как работает UEFI

UEFI загружается строго в согласовании с установленными правилами. Если ОС не поддерживает UEFI, активизируется режим эмуляции BIOS. Процесс загрузки ПК на базе BIOS довольно прост: после нажатия кнопки включения запускается BIOS, которая инспектирует состояние оборудования и загружает микропрограммное обеспечение — обыкновенные драйверы для отдельных аппаратных компонент. После чего BIOS делает поиск загрузчика ОС и активирует его. Тот в свою очередь загружает операционную систему либо выводит на экран перечень доступных ОС.

Компы на базе UEFI загружаются аналогичным образом только до момента поиска характеристик загрузки. После чего все происходит по другому. UEFI имеет свой загрузчик ОС с вставленными менеджерами пуска установленных систем. Для него на диске создается маленький раздел (100–250 Мбайт), отформатированный в файловой системе FAT32, который именуется Extensible Firmware Interface System Partition (системный раздел расширяемого микропрограммного интерфейса, ESP). На нем находятся драйверы аппаратных компонент, к которым может получать доступ запущенная операционная система. Общепринятое правило таково: кроме DVD, UEFI может загружаться только с носителя, отформатированного в файловой системе FAT32.

UEFI — непростой механизм

У ESP есть свои достоинства: благодаря драйверам UEFI и загрузчику ОС, Windows запускается резвее и поболее правильно реагирует на критичные ошибки драйверов. Но интерфейс UEFI накладывает и ограничения: он позволяет устанавливать ОС лишь на жесткие диски, которые размечены по эталону GPT. Последний не поддерживается ни одной версией BIOS, потому что, в отличие от классической схемы разметки (MBR), употребляет адреса секторов длиной 64 бита. Кроме Windows 8 интерфейс UEFI поддерживают только 64-битные версии Windows Vista и 7, также Linux с ядром 3.2 и выше. Более того, для ПК, сертифицированных для работы с «восьмеркой», компания Microsoft предписывает внедрение функции Secure Boot. В этом режиме UEFI запускает только подтвержденные загрузчики ОС, которые содержат драйверы с цифровой подписью Microsoft.

Вместе с Windows 8 только загрузчик Shim (Linux) обладает драйверами с необходимыми для Secure Boot подписями. В других ОС они отсутствуют. Потому, если вы возжелаете установить на схожем компьютере кроме «восьмерки» к тому же Windows 7 либо Vista, нужно открыть меню UEFI и отключить Secure Boot. Если в качестве 2-ой ОС вы выберете несопоставимую с UEFI, для вас будет нужно использовать модуль поддержки сопоставимости (Compatibility Support Module, CSM), который можно включить в UEFI. К огорчению, производители употребляют разные версии UEFI, и время от времени трудно осознать, как отключить Secure Boot и перейти в режим эмуляции BIOS. Эти вопросы мы и разглядим дальше.

Что такое UEFI и как он работает

Процесс загрузки ПК на базе UEFI

Зависимо от конфигурации, UEFI или без помощи других загружает компьютер, или перебегает в режим эмуляции стандартной BIOS. Только после чего запускается менеджер загрузки Windows.

Установка Windows на ПК с UEFI и функцией Secure Boot На ПК с Windows 8 на базе UEFI Secure Boot другие версии ОС можно инсталлировать только при определенных критериях. Юзер должен заблаговременно избрать верный режим загрузки и подходящим образом приготовить установочный флеш-накопитель.

Включение режима эмуляции BIOS Полная путаница: метод перехода в режим эмуляции BIOS находится в зависимости от версии UEFI. На Sony VAIO (1) нужно активировать опцию «Legasy», на ASUS Zenbook (2) — «Launch CSM».

Настройка UEFI

Каждый производитель употребляет в ноутбуках и ультрабуках свою версию UEFI. При всем этом он открывает доступ не ко всем необходимым функциям. Зачастую при загрузке ПК или лэптопа на дисплей не выводится название кнопки, при помощи которой можно вызвать меню настроек UEFI. Мы хотим предложить поступить следующим образом: в интерфейсе Metro перейдите в меню «Параметры | Изменение параметров компьютера» на боковой панели и активируйте пункт «Общие | Особые варианты загрузки». После перезапуска появится менеджер загрузки ОС, который позволит открыть меню UEFI. Исключением является UEFI от HP, где данная опция отсутствует. Здесь поможет следующее: во время загрузки удерживайте нажатой клавишу «Esc». В любом случае необходимо вначале осведомиться, какая кнопка позволяет войти в меню UEFI. Если вы измените режим загрузки на CSM или Legasy BIOS, чтобы загрузиться с аварийной флешки, после операции восстановления необходимо вновь переключиться с CSM на UEFI, иначе Windows 8 не запустится. Да и здесь есть исключения: Aptio Setup Utility на компьютерах ASUS активирует UEFI автоматически при отсутствии совместимого с BIOS загрузочного носителя, поэтому довольно легко отсоединить флешку.

Отключение Secure Boot потребуется в этом случае, если помимо «восьмерки» вы захотите установить 64-битную версию Windows Vista или 7. Иногда поддерживается так называемый гибридный режим, как в устройствах от HP, при котором UEFI может загружаться со всех загрузочных носителей и по мере надобности переключаться в режим BIOS. В широко распространенной версии UEFI InsydeH2O это находится в зависимости от того, предусмотрел ли производитель ноутбука возможность отключения Secure Boot или нет. В Acer Aspire S7 данная функция недоступна, и для ее деактивации нужно переключиться с UEFI в режим BIOS и обратно.

Сложности с восстановлением

С появлением UEFI производители изменили методы работы с системой восстановления ОС. Сочетание клавиш «Alt+F10», которое использовалось ранее, например, в моделях Acer, больше не работает или закреплено за другими функциями. А кнопка «F9» загружает на новом Zenbook не ASUS Preload Wizard, а программу восстановления Windows 8 с расширенным меню загрузки.

Режим восстановления VAIO Care в ноутбуках Sony можно открыть в аналогичном меню, выбрав опцию «Панель управления | Устранение неполадок | Восстановление». Но если запустить менеджер загрузки ОС и выбрать «Диагностика | Восстановить» или «Вернуть в исходное состояние», устройство попросит вставить оригинальный диск Windows 8, которого нет в комплекте поставки. На Acer-моделях бэкап выполняется при помощи предустановленной Windows-программы, а восстановление из резервной копии осуществляется с внешнего USB-носителя. Однако предварительно необходимо зайти в меню UEFI и указать такой диск в качестве загрузочного.

Переход в меню UEFI из Windows

Если активирована функция запуска Windows 8 с расширенными настройками, то, выбрав пункт «Диагностика» (1) и «Дополнительные параметры» (2), можно получить доступ к меню «Параметры встроенного ПО UEFI» (3).

Полезные функции UEFI Каждый производитель ноутбуков использует разные версии интерфейса UEFI и реализует его в системе в соответствии со своими представлениями. Из таблицы, разбитой по моделям, вы узнаете, где находятся основные функции UEFI.

Решение проблемы: отключение Secure Boot В некоторых случаях Secure Boot невозможно деактивировать напрямую. В Acer Aspire S7, например, данная функция недоступна. Но если переключиться в «Legasy BIOS» (1) и снова назад (2), Secure Boot будет отключена.

В гибридном режиме возможно все В версии интерфейса UEFI от HP есть поддержка гибридного режима, в каком, зависимо от загрузочного носителя, запускается один из двух режимов — либо UEFI, либо CSM. При всем этом функция Secure Boot отключается автоматически.

Запуск с флешки

Старые флеш-носители для аварийной загрузки и восстановления работают исключительно в режиме BIOS. Мы сделаем их совместимыми с UEFI.

USB-флешки в ближайшее время все чаще используются в качестве загрузочных носителей для восстановления или установки Windows. Это связано с тем, что в современных ноутбуках очень редко устанавливаются оптические приводы. Если вы изучили настройки UEFI в своем компьютере, рекомендуется также выполнить и апгрейд флеш-накопителей. С появлением UEFI все имеющиеся загрузочные флешки уже не получится использовать привычным образом. Например, если вы создали загрузочный USB-носитель в программе UNetbootin, вам необходимо будет запустить ПК в режиме CSM. То же самое относится ко всем старым флешкам, потому что разработчики дистрибутивов Linux Live (например, GParted) исключительно в последних, наиболее свежих версиях своих приложений начали добавлять загрузчик с поддержкой UEFI и функции Secure Boot.

Наиболее простым является способ, при котором Secure Boot отключается в UEFI, затем при помощи бесплатной программы Rufus создается совместимый с UEFI флеш-накопитель, после этого на него копируется последняя версия GParted.

Программа от Microsoft устарела

В отношении загрузочных USB-носителей с операционной системой Windows действуют несколько иные правила. Для совместимости с UEFI они должны быть отформатированы в файловой системе FAT32. Многие пользователи даже для Windows 8 создают загрузочные накопители на флешках, отформатированных при помощи программы от Microsoft, входящей в состав «семерки». Однако данное приложение по дефлоту форматирует накопитель в файловой системе NTFS, в результате чего имеющуюся на носителе систему впоследствии невозможно установить на компьютер с UEFI. Чтобы не дожидаться выхода обновленной программы от Microsoft, можно создать загрузочный накопитель вручную. Для этого вначале отформатируйте USB-флешку при помощи бесплатной утилиты. Затем откройте в Windows 8 образ ISO и скопируйте находящиеся в нем файлы на носитель.

А вот чтобы совместимый с UEFI флеш-накопитель с 64-битной Windows 7 загружался без каких-либо проблем, вам потребуется скопировать UEFI-загрузчик в нужный каталог на флешке. Для этого, используя бесплатный архиватор 7-Zip, найдите в образе ISO, который содержит установочные файлы Windows 7, в папке Sources файл архива Install.wim и откройте его. После чего из директории 1WindowsBootEFI скопируйте файл bootmgfw.efi. Затем сохраните его на флеш-накопителе в каталоге efiboot и переименуйте, присвоив ему имя bootx64.efi. После чего с USB-носителем можно будет работать в режиме UEFI, и вы сумеете без проблем установить с него Windows 7.

Создание загрузочных флешек на основе Live-систем

Для совместимости с UEFI флешки должны быть отформатированы в FAT32. Например, программа UNetbootin (1) создает загрузочные накопители на основе дистрибутивов Linux Live, форматируя их в FAT. Однако утилита Rufus (2) предлагает более правильную опцию.

Флеш-накопитель для восстановления ОС на ПК с UEFI Флеш-накопители на основе свежих Live-систем, такие как GParted, способны без проблем получать доступ к ПК с UEFI, потому что встроенные в них инструменты — например, GPart (1) и TestDisk (2) — могут работать с GPT-разделами.

Форматирование загрузочной флешки с Windows 64-битную версию Windows 7 можно установить и на ПК с UEFI. Если вы хотите выполнить данную операцию с USB-накопителя, необходимо отформатировать его при помощи Windows-программы DiskPart в файловой системе FAT32 и сделать его загрузочным.

Извлечение UEFI-загрузчика Совместимый с UEFI флеш-накопитель с Windows 7 дополнительно нуждается в загрузчике UEFI — bootmgfw.efi. Его необходимо вручную скопировать из архива install.wim на флешку, используя программу 7-Zip или любой другой архиватор.