Secure Boot Mode — что это в биосе?
Приветствую друзья! Смотрите, интересная ситуация — иногда производители так хотят нам облегчить жизнь, что придумывают всякие заумные настройки, которые должны нас оберегать от появления глюков, от нестабильной работы компьютера/ноутбука. Но часто эти опции только ухудшают нашу компьютерную жизнь. Пример? Пожалуйста — вы купили ноут с Windows 8, а хотите поставить десятку. Но кто бы мог подумать, что производитель посчитает что ставить другую операционку — это получается опасно..
Secure Boot Mode — что это такое?
Режим безопасной загрузки, который не даст запустить ваш ноут/ПК с загрузочного диска кроме Windows 8, Windows 10. Операционка может отличаться от модели ноута. Простыми словами — установить можно то, что советует производитель. Все остальное — на свой страх и риск, будто семерка и десятка — нереально разные операционки.
Поэтому, чтобы установить другую операционку, данную опцию следует отключить, либо выставить значение Custom вместо Standart.
Настройка находится в одном из разделе:
- Security (переводится как безопасность).
- System Configuration (системная конфигурация).
- Boot (переводится как загрузиться с чего-то, там флеша, диск).
Короче суть в том, что производитель сообщает: уважаемые, на этот ноутбук безопасно можно ставить только определенную операционку (или несколько), как будут другие работать — неизвестно, а поэтому небезопасно. Но по факту все преувеличено, там где работает десятка, скорее всего будет работать и семерка, а иногда и Windows XP.
Например если ноутбук поддерживает только десятку, то чтобы установить семерку, нужно не только отключить Secure Boot Mode, нужно еще включить режим совместимости с другими операционками, такая опция может называться:
- Launch CSM
- CMS Boot
- UEFI and Legacy OS
- CMS OS
Вышеперечисленная опция может находится в разделе Advanced > подраздел Boot Mode или OS Mode Selection.
Опция в биосе ASUS:

Как видите — опция также может быть в разделе Security Boot Parameters.
Почему ставить другие операционки — небезопасно?
Вообще попахивает бредом.
Но думаю что корни идут например.. к процессору. Новые процы поддерживают новые инструкции, поэтому например десятка реально может работать быстрее на новом проце чем семерка.
Самый грубый пример — старушка Windows XP, которая медленнее работает чем Windows 10 на новом ПК. Да, с трудом XP можно установить, например я ставил на 1150 сокет.. хотя не оч новый, но суть не в этом.
Да и о чем говорить, когда уже много новых материнок официально не поддерживают Windows 7. Хотя я не считаю что она устаревшая, однако факт есть фактом — ставьте только десятку. Кому-то такой ход не нравится, согласен, но будущее не за горами, когда популярный софт перестанет поддерживать семерку, как например.. Хром перестал поддерживать Windows XP (там работает только последняя версия, старая, которая еще поддерживала XP).
Почему UEFI Secure boot это трудность для Linux
Недавняя публикация на Хабре об ограничениях UEFI вызвала широкое обсуждение, в продолжении темы, хочу поделиться переводом актуального поста из блога Matthew Garrett, одного из разработчиков RedHat.
Я писал о технических деталях поддержки Linux`ом спецификации UEFI Secure boot. Не смотря на то, что я прямо указал, что она игнорирует вопросы лицензирования и распространение ключей, тем не менее опираясь на неё люди утверждают, что поддержка Secure boot может быть добавлена в Linux с минимальными усилиями. В некотором смысле, они правы. Технические детали реализации достаточно просты. Но трудности заключены не в них.
Safe boot требует, что бы весь код, который взаимодействует с железом, был доверенным.
В настоящее время, если вы можете выполнить не доверенный код до загрузки ОС, то можете сделать с ОС всё, что захотите. Secure boot предоставляет механизм, который позволяет быть уверенным, что вы запускаете только доверенный код, что призвано защитить от подобных сценариев. Итак, ваши UEFI драйвера снабжены цифровой подписью, загрузчик так же снабжен цифровой подписью и может загрузить только подписанное ядро. Если для загрузки вами использовался только доверенный код, то вы можете быть уверены, что ваша ОС в безопасности. Но, в отличии от загрузки доверенного кода, Secure boot не даёт вам возможности быть уверенным, что выполняется только доверенный код. Это должно быть обеспечено политиками ОС.
На первый взгляд это не составляет большой проблемы. Но на самом деле является ей. Представьте, что у вас есть подписанный загрузчик Linux и подписанное ядро Linux и эти подписи сделаны с помощью глобального доверенного ключа. Они будут загружаться на любом железе использующем Secure boot. Теперь представьте, что злоумышленник пишет модуль ядра, который создаёт поддельное окружение UEFI, прерывает выполнение кода ядром и вызывает загрузчик Windows — что-то вроде kexec, но чуть более сложное. Загрузчик Windows уверен, что он выполняется в Secure boot, но на самом деле, всё, что на его взгляд заслуживает доверия, является поддельным кодом UEFI, написанным злоумышленником. Ключ шифрования пользователя записывается, ядро Windows модифицируется таким образом, что бы скрыть код Linux и не смотря на то, что всё выглядит замечательно, данные вашей кредитной карточки уже на пути в Китай. В этом сценарии подписанное ядро Linux просто используется как загрузчик вредоносного ПО. Единственным признаком, что что-то не так, является чуть более долгая загрузка ОС.
Подписанного ядра не достаточно. Подписанное ядро Linux должно предотвращать загрузку любых не подписанных модулей ядра. VirtualBox в Linux? До свидания. Бинарные драйверы Nvidia? До свидания. Всё что выходит за пределы стандартных модулей ядра? Так же до новых встреч. Самостоятельная сборка новых драйверов? В другой раз. Всё это явно не сделает людей счастливее.
(Тоже самое, конечно, касается и Windows. Windows 7 позволяет запретить проверку цифровой подписи драйверов, но Windows 8 не позволит этого сделать, если система использует механизм Secure boot).
Лицензирование
GPLv3 имеет различные требования к доступности ключей используемых для подписи. Согласно новым требованиям Microsoft, система должна поддерживать установку пользовательских ключей, что позволит пользователям использовать их собственные загрузчики ОС, этого вполне может быть достаточно, что бы соблюсти требования лицензии. Но мы попадаем в зависимость от Microsoft — если они уберут это требование, то пользователи теряют свою свободу и мы оказываемся в неловком положении с вопросом о лицензировании. Обсуждения о том, что конкретно мы сможем предпринять в этом случае, еще продолжаются, но на текущей момент эта проблема не решена.
Распространение ключей
Спецификация UEFI не определяет, кто будет являться центральным удостоверяющим центром. Microsoft настаивает, что бы каждый имел свой собственный ключ. Мы, конечно, можем сгенерировать собственные ключи, но не всё так просто с производителями оборудования. Не существует пути, который гарантировал бы, что все производители железа поддержат их. И, очевидно, если мы сгенерируем ключ, мы не сможем просто передать его приватную часть третьим лицам. Это значит, что для людей станет невозможным выпуск собственных дистрибутивов, основанных на других, без получения их личного ключа. Для получения ключа будет требоваться какая-либо процедура проверки идентификации, которая, вероятно, окажется дорогостоящей, и так же вероятно, что может потребоваться легально зарегистрированная организация, для обеспечения проверки идентификационных данных. Думаю, это будут сертификаты Extended Validation, а не Startssl Free. Таким образом, диструбутивы Linux созданные энтузиастами, окажутся в прошлом.
Разве Custom mode не решает эту проблему?
Сертификационные требования Microsoft указывают, что все системы должны поддерживать Custom mode, реализация этой функции должна обеспечить возможность пользователям устанавливать их собственные ключи. Производители Linux смогут поставлять их собственные ключи вместе с дистрибутивом и устанавливать собственные политики. Все счастливы. На самом деле, всё не так хорошо. Людям придётся тратить невероятное количество времени и усилий для того чтобы установить Linux, вместо того, чтобы просто вставить CD в привод. Потребность изменения прошивки и её перенастройка добавляет дополнительный барьер и ограничивает возможность установки Linux лишь более технически грамотными пользователями. А это еще хуже. Вот полное описание требований к Custom mode:
1. Для физически находящегося за устройством пользователя, должна быть возможность использования режима Custom mode, для модифицирования содержимого базы данных сигнатур Secure boot и PK (прим. переводчика: PK — private key).
2. Если пользователь удаляет PK, то при выходе из режима Custom mode, система будет функционировать в режиме Setup Mode c выключенным по-умолчанию Secure Boot.
3. Меню настройки прошивки должно уведомлять о включении Secure boot, а так же о режиме функционирования Standard или Custom mode. Меню настройки так же должно предоставлять возможность возвратиться от Custom к Standard mode, с восстановлением заводских настроек по-умолчанию.
Здесь кое-что упущено, например:
— Какое-либо описание UI. Это делает фактически невозможным документирование процесса установки Linux, когда первый шаг (а) запутан и (б) зависит от производителя. Производители железа стараются выделить себя, предлагая свои собственные уникальные интерфейсы прошивок. Custom mode в них может выглядеть совершенно по-разному.
— Какое-либо описание формата ключа. Простое бинарное представление ключа? Или структура EFI_SIGNATURE_DATA? Ключ в кодировке base64, далее защищенный ROT13? Мы просто не знаем.
— Какой-либо путь для использования режима Custom mode при unattended-варианте установки ОС. Интерфейс прошивки требует физического присутствия пользователя. Желаете установить ОС на несколько тысяч машин по сети? Это не масштабируемый подход.
— … и одна мелочь, на самом деле, нигде нет требований, что бы пользователь мог сам добавлять ключ, производители железа могут воспользоваться этим, разрешив лишь удалять ключи. Это не плохо, пока пользователи могут удалять PK, потому-что затем они вернутся обратно в Setup mode и смогут установить наши ключи из установщика, но на практике это по-прежнему будет вызывать проблемы.
Всё таки Custom mode не решает всех проблем. Custom mode с строго определенным UI и форматом ключа был бы на много лучше, но по-прежнему не решит проблему с автоматическим unattended-вариантом установки ОС.
Как включить Secure Boot в BIOS на Gigabyte и AORUS
Одним из системных требований Windows 11 является наличие безопасной загрузки Secure Boot. Эта функция является частью UEFI и предназначена для проверки запускаемых операционных систем. Secure Boot проверяет цифровую подпись и в случае ошибки блокирует загрузку ОС. Это позволяет защититься от некоторых видов вредоносных программ и контролировать список ОС, которые могут загружаться на компьютере.
После анонса Windows 11 начали интересоваться включением данной опции, чтобы подготовить компьютер к обновлению до новой операционной системы. В этой статье мы расскажем, как включить Secure Boot в BIOS на материнских платах Gigabyte и Gigabyte AORUS.
Для работы Secure Boot диск должен быть в формате GPT. Поэтому, перед включением Secure Boot нужно проверить формат диска и если диск в MBR, то его нужно сконвертировать в GPT. Подробнее:
Процесс включения Secure Boot может сильно отличаться от одной материнской платы к другой. Точную информацию для вашей конкретной материнской платы можно получить в инструкции. Ниже мы рассмотрим несколько типичных вариантов для BIOS на платах Gigabyte и Gigabyte AORUS.
Для того чтобы включить Secure Boot на материнских платах Gigabyte или Gigabyte AORUS нужно зайти в настройки BIOS и открыть раздел « BOOT » или « BIOS ». Содержимое этих разделов похожее, но в зависимости от модели платы, название может отличаться.


Дальше нужно отключить функцию « CSM Support » если она включена. CSM или Compatibility Support Module – это функция эмуляции старого BIOS, позволяющая загружать операционную систему с жестких дисков с разметкой MBR. Без отключения CSM вы не сможете включить Secure Boot.

После этого нужно открыть раздел « Secure Boot ». Обратите внимание, если функция « CSM Support » включена, то раздел « Secure Boot » может не отображаться в меню.

И включить опцию « Secure Boot Enable ». После этого необходимо сохранить настройки BIOS и перезагрузить компьютер.

После включение Secure Boot можно проверить ее состояние с помощью программы « Сведения о системе », которая доступна в Windows 10. Для этого нажмите комбинацию клавиш Win-R и выполните команду « msinfo32 ».

В открывшемся окне нужно найти строки « Режим BIOS » и « Состояние безопасной загрузки ». Если все было сделано правильно, то здесь должно быть указано « UEFI » и « Включено », как на скриншоте вверху.
Возможно вам будет интересно:
- Как проверить совместимость компьютера с Windows 11
- Что такое Secure Boot для Windows 11
- Программа для проверки совместимости с Windows 11
- Запуск Windows 11 на этом компьютере невозможен
- Как включить Secure Boot в BIOS на MSI
Создатель сайта comp-security.net, автор более 2000 статей о ремонте компьютеров, работе с программами, настройке операционных систем.
Задайте вопрос в комментариях под статьей или на странице «Задать вопрос» и вы обязательно получите ответ.
Не выключается csm. материнка gigabyte h110m-s2.
Если компьютер не загружается после выключения, то скорее всего у вас диск в MBR и его нужно конвертировать в GPT.
Я выключаю csm а она включается обратно. А Secure Boot ругается на то что СSM включен
Диск в MBR или GPT? Если в MBR, то конвертируйте в GPT и снова попробуйте отключить CSM.
Как подсказали внизу в комментариях, вероятно, что-то из вашего оборудование не поддерживает UEFI, скорее всего видеокарта. Поэтому BIOS автоматически включает CSM, чтобы компьютер запустился.
После всех манипуляций система после сохранения настроек все время перезаходит в Биос, ТК перестает видеть все загрузочные диски с системой и без нее. Как это лечить. Gigabyte b550 aorus ac pro
Fix System in Setup Mode Secure Boot Can Be Enabled When System In User Mode
If you are trying to enable secure boot then you might see an error reading “System in Setup Mode! Secure Boot can be enabled when System in User Mode.” while enabling secure boot in the UEFI menu. Due to this error message, you will not be able to enable Secure Boot from the UEFI menu. And you won’t be able to play games that require the secure boot, like Valorant.
So here, in this guide, you will find an easy way to fix the enable secure boot by enabling the system in user mode.
Fix: System in Setup Mode Secure Boot Can Be Enabled When System In User Mode
If you open the UEFI menu, navigate to Windows OS Configuration and then click on Secure Boot, you will see the option to enable or disable it.

But if you click on Enable, you will see an error message reading “System in Setup Mode! Secure Boot can be enabled when System in User Mode. Repeat operation after enrolling Platform Key(PK)”.

Usually, this happens when your system is running in CSM mode and you change it to UEFI or your system already has some platform keys enrolled.
Now here is how to fix it:
Step 1: Open the Secure Boot menu.
Step 2: Change the Secure Boot Mode to Custom from Standard.

Step 3: Now click on Enroll all Factory Default Keys.
Step 4: Click on Yes.

Step 5: Then click on No for Reset Without Saving?
Step 6: Now click on Secure Boot again and then click on Enable.
Step 7: Change the Secure Boot Mode to Standard again.
Step 8: For the Install factory defaults option, click on Yes.

Step 9: Then click on No for Reset Without Saving?


Your Secure Boot Menu will look like this
Step 10: Exit the UEFI menu, click on Yes for the Save configuration and exit? menu.

That’s it! Now your system will restart and Secure Boot will be enabled. You will also be able to enable TPM 2.0.
Hopefully, this quick and short method is going to fix any issues that you are having with Secure Boot and you will be able to play Valorant without any issues.
In case of any difficulty, feel free to comment down below or reach out to us. We are definitely going to help you with any queries.