Enroll all factory default keys что это в биосе

В том случае, если компьютер поддерживает Secure Boot, можно просто активировать безопасную загрузку:

1. Перезагрузить компьютер и войти в UEFI (aka BIOS) и включите Secure Boot. Конкретные местонахождения параметров настройки зависят от производителя ПК и настроек среды UEFI (ниже мы привели список типовых настроек Secure Boot в различных UEFI)
   
   
2. Если первый вариант не помог, попробуйте сбросить настройки BIOS/UEFI на заводские (factory default)

Enroll all factory default keys что это в биосе

У большинства прошивок, основанных на коде AMI, управление технологией SecureBoot находится на вкладке Security, у меня это управление выглядит так:

Заходим в меню Key Management (раньше оно было на той же вкладке, сейчас его выделили в отдельное) и видим там следующее:

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

Теперь предлагается либо установить значение по умолчанию, либо загрузить собственное из файла, выбираем последнее:

Далее нужно устройство и файл на нем, а затем выбрать формат этого файла, в нашем случае это Authenticated Variable:

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

Повторяем то же самое для KEK и PK, и получам на выходе вот такое состояние:

Все верно, у нас есть единственный PK, всего один ключ в KEK и три ключа в db, возвращаемся в предыдущее меню кнопкой Esc и включаем SecureBoot:

Готово, сохраняем настройки и выходим с перезагрузкой, после чего пытаемся загрузиться с нашей флешки и видим вот такую картину:

Отлично, неподписанные загрузчики идут лесом, осталось проверить подписанный. Вставляем другую флешку, перезагружаемся и видим что-то такое:

Вот теперь можно сказать, что SecureBoot работает как надо.
Если у вашего AMI UEFI такого интерфейса для добавления ключей нет, то вам подойдет другой способ, о котором далее.

Insyde H2O

Здесь все несколько хуже, чем в предыдущем случае. Никакого интерфейса для добавления собственных ключей нет, и возможностей настройки SecureBoot предлагается всего три: либо удалить все переменные разом, переведя SecureBoot в Setup Mode, либо выбрать исполняемый файл, хеш которого будет добавлен в db, и его можно будет запускать даже в том случае, если он не подписан вообще, либо вернуться к стандартным ключам, в качестве которых на этой машине выступают PK от Acer, по ключу от Acer и MS в KEK и куча всякого от Acer и MS в db.
Впрочем, нет интерфейса — ну и черт с ним, у нас для этого KeyTool есть, главное, что в Setup Mode перейти можно. Интересно, что BIOS Setup не дает включить SecureBoot, если пароль Supervisor Password не установлен, поэтому устанавливаем сначала его, затем выполняем стирание ключей:

После чего на соседней вкладке Boot выбираем режим загрузки UEFI и включаем SecureBoot:

Т.к. фотографии у меня посреди ночи получаются невыносимо отвратительными, то скриншоты KeyTool‘а я сделаю на предыдущей системе, и придется вам поверить в то, что на этой все выглядит точно также (мамой клянусь!).
Загружаемся с нашего носителя в KeyTool, и видим примерно следующее:

Выбираем Edit Keys, попадаем в меню выбора хранилища:

Там сначала выбираем db, затем Replace Keys, затем наше USB-устройство, а затем и файл:

Нажимаем Enter и без всяких сообщений об успехе нам снова показывают меню выбора хранилища. Повторяем то же самое сначала для KEK, а затем и для PK, после выходим в главное меню двойным нажатием на Esc. Выключаем машину, включаем заново, пытаемся загрузить KeyTool снова и видим такую картину (которую я утащил из дампа прошивки, ее фото на глянцевом экране еще кошмарнее, чем предыдущие):

Ну вот, одна часть SecureBoot’а работает, другая проверяется запуском подписанной нами RU.efi и тоже работает. У меня на этой системе Windows 8 установлена в UEFI-режиме, так вот — работает и она, Microsoft с сертификатом не подвели.

Phoenix SCT

Здесь возможностей еще меньше, и во всем меню Secure Boot Configuration на вкладке Security всего два пункта: возврат к стандартным ключам и удаление всех ключей с переводом системы в SetupMode, нам нужно как раз второе:

Затем на вкладке Boot нужно выбрать тип загрузки UEFI, включить SecureBoot, и создать загрузочную запись для KeyTool‘а, иначе на этой платформе его запустить не получится:

Нажимаем Yes, выходим с сохранением изменений, перезагружаемся, нажимаем при загрузке F12, чтобы попасть в загрузочное меню, оттуда выбираем KeyTool, работа с которым описана выше. После добавления ключей и перезагрузки попытка повторного запуска KeyTool‘а заканчивается вот так:

При этом установленный на той же машине Linux продолжает исправно загружаться, как и подписанная нами RU.efi, так что SecureBoot можно признать работоспособным.

Безопасная загрузка (SecureBoot) настроена неправильно в Windows 8.1

01.11.2013
itpro
Windows 8
комментариев 49

• — настроена корректная политика Secure Boot.
• Любой другой GUID – используется непродуктивная (тестовая или отладочная) политика безопасной загрузки.
• Secure Boot policy is not enabled on this machine (Политика безопасной загрузки на этом компьютере не включена) — компьютер не поддерживает Secure Boot или работает в Legacy режиме

1. Перезагрузить компьютер и войти в UEFI (aka BIOS) и включите Secure Boot. Конкретные местонахождения параметров настройки зависят от производителя ПК и настроек среды UEFI (ниже мы привели список типовых настроек Secure Boot в различных UEFI)
   
   
2. Если первый вариант не помог, попробуйте сбросить настройки BIOS/UEFI на заводские (factory default)

Укрощаем UEFI SecureBoot

Данные обещания надо выполнять, тем более, если они сделаны сначала в заключительной части опуса о безопасности UEFI, а потом повторены со сцены ZeroNights 2015, поэтому сегодня поговорим о том, как заставить UEFI SecureBoot работать не на благо Microsoft, как это чаще всего настроено по умолчанию, а на благо нас с вами.
Если вам интересно, как сгенерировать свои собственные ключи для SecureBoot, как установить их вместо стандартных (или вместе с ними), как подписать ваш любимый EFI-загрузчик, как запретить загрузку неподписанного или подписанного чужими ключами кода, как выглядит интерфейс для настройки SecureBoot у AMI, Insyde и Phoenix и почему это, по большому счету, совершенно не важно — добро пожаловать под кат, но опасайтесь большого количества картинок и длинных консольных команд.

Введение

С ликбезом закончили, теперь к делу. Несмотря на то, что про создание своих ключей и настройку SecureBoot написано за три последних года с десяток отличных статей (ссылки на часть из которых приведены в разделе Литература), воз и ныне там. Основная проблема с информацией о настройке SecureBoot даже в англоязычном сегменте сети (не говоря уже о рунете) — большая часть статей, текстов и постов обрывается на «вот у нас теперь есть ключи в формате EFI Signature List, добавьте их зависимым от вашего вендора прошивки способом и готово». При этом сами вендоры не торопятся описывать меню настройки SecureBoot ни в документации на свои платформы для OEM’ов, ни в мануалах на конечные системы, в результате пользователь теряется на незнакомой местности и либо отключает SecureBoot, мешающий загружать его любимую OpenBSD (или что там у него), либо оставляет его на настройках по умолчанию (а чего, Windows грузится же). Именно этот последний шаг я и попытаюсь описать более подробно, но не в ущерб остальным необходимым шагам.

Тестовая конфигурация

Специально для этой статьи я достал из закромов пару не самых новых ноутбуков с прошивками на платформах Phoenix SCT и Insyde H2O, а также совершенно новую плату congatec (разработкой прошивки для которой я занят в данный момент) на платформе AMI AptioV. Встречайте, наши тестовые стенды:

1. AMI, они же «треугольные«: congatec conga-TR3 @ conga-TEVAL, AMD RX-216GD (Merlin Falcon), AMI AptioV (UEFI 2.4)

2. Insyde, они же «квадратные«: Acer Aspire R14 R3-471T (Quanta ZQX), Intel Core i3-4030U (Ivy Bridge), Insyde H2O (UEFI 2.3.1C)

3. Phoenix, они же «полукруглые«: Dell Vostro 3360 (Quanta V07), Intel Core i7-3537U (Ivy Bridge), Phoenix SCT (UEFI 2.3.1C)

Об интерфейсах для настройки SecureBoot

Готовим плацдарм

Начнем с лирического отступления о наличии нужного софта для разных ОС. Несмотря на то, что Microsoft является одним из разработчиков технологии, в открытом доступе до сих пор отсутствуют нормальные средства для работы с ней из Windows (ключи можно сгенерировать утилитой MakeCert из Windows SDK, а для всего остального предлагается использовать HSM третьих лиц за большие деньги). Я подумывал сначала взять и написать нужную утилиту на Qt, но потому решил, что ключи и подписи каждый день генерировать не нужно, а на пару раз хватит и существующих решений. Можете попробовать переубедить меня в комментариях, если хотите.
В общем, для всего нижеперечисленного вам понадобится Linux (который можно запустить с LiveUSB, если он у вас не установлен). Для него существует целых два набора утилит для работы с SecureBoot: efitools/sbsigntool и EFIKeyGen/pesign. У меня есть положительный опыт работы с первым набором, поэтому речь пойдет именно о нем.
В итоге, кроме Linux, нам понадобятся несколько вещей:
1. Пакет openssl и одноименная утилита из него для генерирования ключевых пар и преобразования сертификатов из DER в PEM.
2. Пакет efitools, а точнее утилиты cert-to-efi-sig-list, sign-efi-sig-list для преобразования сертификатов в формат ESL и подписи файлов в этом формате, и KeyTool.efi для управления ключами системы, находящейся в SetupMode.
3. Пакет sbsigntool, а точнее утилита sbsign для подписи исполняемых файлов UEFI (т.е. загрузчиков, DXE-драйверов, OptionROM’ов и приложений для UEFI Shell) вашим ключом.
Загрузите Linux, установите вышеуказанные пакеты, откройте терминал в домашней директории и переходите к следующему шагу.

Генерируем собственные ключи для SecureBoot

Как обычно, есть несколько способов сделать что-либо, и чем мощнее используемый инструмент, тем таких способов больше. OpenSSL же как инструмент развит настолько, что кажется, что он умеет делать вообще всё, а если почитать к нему man — то и абсолютно всё остальное. Поэтому в этой статье я ограничусь непосредственной генерацией ключевых файлов, а танцы вокруг создания собственного CA оставлю на самостоятельное изучение.

Генерируем ключевые пары

Конвертируем открытые ключи в формат ESL

Теперь нужно сконвертировать открытые ключи из формата PEM в понятный UEFI SecureBoot формат ESL. Этот бинарный формат описан в спецификации UEFI (раздел 30.4.1 в текущей версии 2.5) и интересен тем, что файлы в нем можно соединять друг с другом конкатенацией, и этот факт нам еще пригодится.
Ключ -g добавляет к сгенерированному ESL-файлу GUID, в нашем случае — случайный, полученый запуском утилиты uuidgen и использованием ее вывода. Если этой утилиты у вас нет — придумывайте GUIDы сами или оставьте значение по умолчанию.

Подписываем ESL-файлы

С другой стороны, если вы не хотите терять возможность загрузки Windows и подписанных ключом Microsoft исполняемых компонентов (к примеру, GOP-драйверов внешних видеокарт и PXE-драйверов внешних сетевых карточек), то к нашему ISK.esl надо будет добавить еще пару ключей — ключ Microsoft Windows Production CA 2011, которым MS подписывает собственные загрузчики и ключ Microsoft UEFI driver signing CA, которым подписываются компоненты третьих сторон (именно им, кстати, подписан загрузчик Shim, с помощью которого теперь стартуют разные дистрибутивы Linux, поддерживающие SecureBoot из коробки).
Последовательность та же, что и под спойлером выше. Конвертируем из DER в PEM, затем из PEM в ESL, затем добавляем к db.esl, который в конце концов надо будет подписать любым ключом из KEK:

Теперь подписываем PK самим собой:
Подписываем KEK.esl ключом PK:
Подписываем db.esl ключом KEK:

Если еще не надоело, можно добавить чего-нибудь еще в db или создать хранилище dbx, нужные команды вы теперь знаете, все дальнейшее — на ваше усмотрение.

Подписываем загрузчик

Осталось подписать какой-нибудь исполняемый файл ключом ISK, чтобы проверить работу SecureBoot после добавления ваших ключей. Для тестов я советую подписать утилиту RU.efi, она графическая и яркая, и даже издалека видно, запустилась она или нет. На самом деле, утилита эта чрезвычайно мощная и ей можно натворить немало добрых и не очень дел, поэтому после тестов лучше всего будет её удалить, и в дальнейшем подписывать только загрузчики.
В любом случае, подписываются исполняемые файлы вот такой командой:
Здесь я заодно переименовал исполняемый файл в bootx64.efi, который нужно положить в директорию /EFI/BOOT тестового USB-носителя с ФС FAT32. Для 32-битных UEFI (избавь вас рандом от работы с ними) используйте bootia32.efi и RU32.efi.

В результате вот этого всего у вас получились три файла .auth, которые нужно будет записать «как есть» в NVRAM-переменные db, KEK и PK, причем именно в таком порядке. Скопируйте все три файла в корень другого USB-носителя с ФС FAT32, на котором в качестве /EFI/BOOT/bootx64.efi выступит /usr/share/efitools/efi/KeyTool.efi (скопируйте его еще и в корень, на всякий случай) и ваш «набор укротителя SecureBoot» готов.

Укрощение строптивого

AMI AptioV

У большинства прошивок, основанных на коде AMI, управление технологией SecureBoot находится на вкладке Security, у меня это управление выглядит так:

Заходим в меню Key Management (раньше оно было на той же вкладке, сейчас его выделили в отдельное) и видим там следующее:

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

Теперь предлагается либо установить значение по умолчанию, либо загрузить собственное из файла, выбираем последнее:

Далее нужно устройство и файл на нем, а затем выбрать формат этого файла, в нашем случае это Authenticated Variable:

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

Повторяем то же самое для KEK и PK, и получам на выходе вот такое состояние:

Все верно, у нас есть единственный PK, всего один ключ в KEK и три ключа в db, возвращаемся в предыдущее меню кнопкой Esc и включаем SecureBoot:

Готово, сохраняем настройки и выходим с перезагрузкой, после чего пытаемся загрузиться с нашей флешки и видим вот такую картину:

Отлично, неподписанные загрузчики идут лесом, осталось проверить подписанный. Вставляем другую флешку, перезагружаемся и видим что-то такое:

Вот теперь можно сказать, что SecureBoot работает как надо.
Если у вашего AMI UEFI такого интерфейса для добавления ключей нет, то вам подойдет другой способ, о котором далее.

Insyde H2O

Здесь все несколько хуже, чем в предыдущем случае. Никакого интерфейса для добавления собственных ключей нет, и возможностей настройки SecureBoot предлагается всего три: либо удалить все переменные разом, переведя SecureBoot в Setup Mode, либо выбрать исполняемый файл, хеш которого будет добавлен в db, и его можно будет запускать даже в том случае, если он не подписан вообще, либо вернуться к стандартным ключам, в качестве которых на этой машине выступают PK от Acer, по ключу от Acer и MS в KEK и куча всякого от Acer и MS в db.
Впрочем, нет интерфейса — ну и черт с ним, у нас для этого KeyTool есть, главное, что в Setup Mode перейти можно. Интересно, что BIOS Setup не дает включить SecureBoot, если пароль Supervisor Password не установлен, поэтому устанавливаем сначала его, затем выполняем стирание ключей:

После чего на соседней вкладке Boot выбираем режим загрузки UEFI и включаем SecureBoot:

Т.к. фотографии у меня посреди ночи получаются невыносимо отвратительными, то скриншоты KeyTool‘а я сделаю на предыдущей системе, и придется вам поверить в то, что на этой все выглядит точно также (мамой клянусь!).
Загружаемся с нашего носителя в KeyTool, и видим примерно следующее:

Выбираем Edit Keys, попадаем в меню выбора хранилища:

Там сначала выбираем db, затем Replace Keys, затем наше USB-устройство, а затем и файл:

Нажимаем Enter и без всяких сообщений об успехе нам снова показывают меню выбора хранилища. Повторяем то же самое сначала для KEK, а затем и для PK, после выходим в главное меню двойным нажатием на Esc. Выключаем машину, включаем заново, пытаемся загрузить KeyTool снова и видим такую картину (которую я утащил из дампа прошивки, ее фото на глянцевом экране еще кошмарнее, чем предыдущие):

Ну вот, одна часть SecureBoot’а работает, другая проверяется запуском подписанной нами RU.efi и тоже работает. У меня на этой системе Windows 8 установлена в UEFI-режиме, так вот — работает и она, Microsoft с сертификатом не подвели.

Phoenix SCT

Здесь возможностей еще меньше, и во всем меню Secure Boot Configuration на вкладке Security всего два пункта: возврат к стандартным ключам и удаление всех ключей с переводом системы в SetupMode, нам нужно как раз второе:

Затем на вкладке Boot нужно выбрать тип загрузки UEFI, включить SecureBoot, и создать загрузочную запись для KeyTool‘а, иначе на этой платформе его запустить не получится:

Нажимаем Yes, выходим с сохранением изменений, перезагружаемся, нажимаем при загрузке F12, чтобы попасть в загрузочное меню, оттуда выбираем KeyTool, работа с которым описана выше. После добавления ключей и перезагрузки попытка повторного запуска KeyTool‘а заканчивается вот так:

При этом установленный на той же машине Linux продолжает исправно загружаться, как и подписанная нами RU.efi, так что SecureBoot можно признать работоспособным.

Заключение

В итоге, благодаря утилитам с открытым кодом, удалось завести SecureBoot на системах с UEFI трех различных вендоров, сгенерировать свои собственные ключи и подписать ими нужные нам исполняемые файлы. Теперь загрузка платформы целиком в наших руках, но только в случае, если пароль на BIOS стойкий и не хранится открытым текстом, как у некоторых, а в реализации SecureBoot нет каких-либо известных (или еще неизвестных) дыр. Сам по себе SecureBoot — не панацея от буткитов, но с ним ситуация с безопасной загрузкой все равно намного лучше, чем без него.
Надеюсь, что материал вам поможет, и спасибо за то, что прочитали эту портянку.

Secure Boot – что это за утилита и как её отключить

Эта утилита – специфический предохранитель, который не дает пользователям устанавливать на компьютер с Windows 8, 8.1 и 10 любую другую ОС .

Работа встроенной в BIOS (UEFI) утилиты заключается в сравнении специальных ключей с подписями загрузочного кода системы.

При несовпадении Secure Boot прекращает загрузку с целью защиты компьютера от взлома и использования нелицензионного программного обеспечения.

Для загрузки любой другой операционной системы на ПК от пользователя требуется сначала отключить эту утилиту в интерфейсе UEFI.

Рис.1. Сообщение при попытке поставить новую систему на компьютер с Security Boot.

Принцип работы и особенности Secure Boot

Технологию защиты системы от переустановки придумали не разработчики Microsoft, а специалисты из компании Unified EFI Forum, создавшей новый интерфейс БИОС – UEFI.

Функция предусматривает возможность отключения запрета установки другой ОС и управления ключами на любом ноутбуке и стационарном ПК.

Не получится отключить Secure Boot (SB) только на планшете под управлением Windows.

Для компьютеров с Windows 8 и 10 утилита работает в двух режимах:

• Режим Setup, необходимый для настройки и позволяющий заменить основные ключи Platform Key и KEK, а также базы разрешённых и отозванных ключей DB и DBX;
• Режим User или режим пользователя, в котором компьютер работает по умолчанию.

Для того, чтобы убрать функцию следует воспользоваться первым режимом.

Замена ключей, которые сравниваются с подписями кода, позволит обойти ограничение на переустановку.

Определение режима загрузки

Узнать о том, что на вашем ПК или ноутбуке включена функция Secure Boot можно тремя способами:

• уже во время попытки поставить новую Windows вместо старой, когда у вас не получится это сделать, а система выдаст соответствующее сообщение;
• через меню msinfo32, которое можно вызвать с помощью окна «Выполнить» и введённой в нём одноимённой команды. Здесь следует найти пункт «Состояние безопасной загрузки» и прочитать там информацию о режиме защиты;

Рис.2. Вход в меню «Свойств системы».

• путём запуска в командной строке (открытой от имени администратора) команды Confirm-SecureBootUEFI. Если режим работает, на экране появится надпись True, если не работает – False. Другие сообщения, включая Cmdlet not supported on this platform, говорят о полном отсутствии поддержки SB компьютером.

Рис.3. Сообщение, показывающее отсутствие поддержки UEFI и Secure Boot.

После определения режима, в котором работает Secure Boot, следует проверить тип его политики с помощью той же командной строки. Для этого вводится уже другая команда – Get-SecureBootPolicy.

Она может вернуть значение <77FA9ABD-0359-4D32-BD60-28F4E78F784B>, что говорит о правильно настроенной политике безопасности.

Любые другие символы показывают, что безопасная загрузка работает в тестовом режиме.

Сообщение типа Secure Boot policy is not enabled on this machine означает, что режим не поддерживается материнской платой.

Отключение утилиты

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

• Войти в настройки интерфейса UEFI;
• Изменить настройки БИОС одним из возможных способов, в зависимости от производителя материнской платы.

На компьютерах с Виндовс 8 и выше существует 2 основных способа входа в БИОС:

• Перейти в правой панели в меню «Параметры», выбрать изменение параметров, затем «Обновление и восстановление» и просто «Восстановление»;
• После этого выбирается пункт «Перезагрузить», затем настройки ПО UEFI. Осталось подождать перезагрузки, после чего вход в интерфейс БИОС будет выполнен автоматически;
• Нажать при включении компьютера функциональную клавишу (Delete, F2 или другие).

После того как удалось войти в интерфейс, следует найти в его настройках пункт, отвечающий за отключение.

Он зависит от конкретной модели компьютера и марки материнской платы.

Например, для ноутбуков HP в БИОС следует найти вкладку System Configuration, перейти к пункту Boot Options и изменить значение показателя Secure Boot на Disabled.

После сохранения изменений и перезагрузки компьютера никаких ограничений на установку ОС остаться не должно.

Устройства Lenovo и Toshiba имеют вкладку Security, а Dell – меню UEFI Boot, где тоже следует отключить Secure Boot.

Рис.4. Отключение безопасной загрузки для модели ноутбука Lenovo.

Для устройств Asus, кроме отключения, требуется дополнительно выбрать возможность установки новой ОС, установив параметр Other OS в пункте OS Type.

На стационарных компьютерах Asus функцию отключают, перейдя в раздел Authentication. А для плат марки Gigabyte требуется переход в меню BIOS Features.

Исправление неполадок

Иногда настройки Secure Boot могут оказаться неправильными.

В этом случае, даже установив систему, в углу рабочего стола можно увидеть сообщение об ошибке типа «Профессиональная Безопасная загрузка (SecureBoot) настроена неправильно Build 9600».

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

• Определение одним из трёх известных способов, работает ли в настоящее время Secure Boot;
• Проверка типа политики безопасности;
• Если режим отключён, для устранения надписи о проблемах с безопасностью следует его включить (при установке системы можно снова выбрать отключение SB), перезагрузить компьютер, войти в БИОС и включить Secure Boot.

Рис.5. Включение SB в настройках UEFI материнской платы AsRock для решения неполадки.

Если применённый метод не помог устранить проблему, настройки UEFI следует попробовать сбросить до заводских.

Для этого в БИОС есть пункт Factory Default. При отсутствии поддержки этого режима у компьютера решить вопрос, скорее всего, не получится.

Единственный возможный вариант – установка таких обновлений от Microsoft, как KB288320, которое находится в составе пакета GA Rollup A.

Скачать его можно с официального сайта производителя, обязательно учитывая разрядность вашей системы – х86 или 64.

Нужен ли пользователям Secure Boot?

Появление функции было неоднозначно воспринято пользователями Windows.

С одной стороны, её использование мешает переустановке операционной системы и, таким образом, ограничивает владельца ноутбука или ПК в своих действиях.

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

Для того чтобы разобраться с этим вопросом, стоит подробнее рассмотреть особенности утилиты:

1. Конкретное назначение Secure Boot – инициализация операционной системы при её загрузке и передача управления загрузчику ОС;
2. Secure Boot представляет собой не встроенную в Windows 8 или 10 функцию, а версию протокола UEFI. Но уже сам интерфейс входит в состав загрузки Виндовс;
3. Система использует SB для безопасности загрузки платформы, и настройка утилиты выполняется производителем устройства, а не операционной системы – то есть компаниями HP, Dell, Lenovo и т. д.;
4. Microsoft не контролирует установку Secure Boot на компьютеры, независимо от того какая система на них установлена (Windows 7, 8 или 10 с разрядностью 32 или 64).

Функция безопасности начинает работать сразу же после включения питания компьютера, запрещая установку новых систем.

Таким образом, пользователь не может использовать для изменения ОС ни жёстким диском, ни сетевой картой, ни CD, DVD или USB-флешкой.

И, хотя производитель утверждает, что функция легко может быть отключена (пусть даже это и не даст загружаться установленной лицензионной системе), сертификация Win-8 может привести к другому результату.

Microsoft требует от разработчиков ПК и ноутбуков только установки Secure Boot, но не обязывает предусмотреть возможность её отключения.

Кроме того, согласно требованиям сертификации Win-8, устанавливать ключи, отличные от защиты MS, тоже не обязательно.

Получается, что возможна такая ситуация, когда производитель выпустит компьютер с Secure Boot, который будет нельзя отключить, и системой, которая уже установлена на устройстве, придётся пользоваться постоянно.

А, значит, пользователю необходимо знать о такой возможности перед покупкой ноутбука или ПК, чтобы не отключаемый SB не стал неприятным сюрпризом.