[Цитировать]

    dialmak
  • 2607
  • Стаж: 8 лет 1 месяц
  • Сообщений: 842
  • Репутация:40

    [+] [-]
Как известно BIOS умирает, его заменяет UEFI, процесс необратим.
К сожалению мало инфы по некоторым нюансам использования SecureBoot.
Цель данной темы рассмотреть, как можно сожительствовать с SecureBoot не испытывая никаких проблем.

x64 и x32 UEFI.

x64 и x32 UEFI.
Как ни прискорбно, но x32 UEFI умер не приходя в сознание, поэтому мы его рассматривать не будем в принципе.

Простой пример.

Простой пример. Я прихожу к незнакомому компу, хочу запустить какие-то уже проверенные практикой EFI приложения - бутлоадер\прогу (самый простой пример rEFInd\grub2) и получаю облом. Ибо включен SecureBoot.
Постараюсь в двух словах пояснить как без изменений настроек UEFI все таки запустить эти EFI приложения. Ничего космического, данная возможность предусмотрена и заложена в самом механизме SecureBoot. После окончания работы с незнакомым компом можно удалить все изменения, это я написал для конспирологов и параноиков.

Немного теории.

Не буду сильно влезать в теорию. Есть 4 режима работы SecureBoot.
Setup Mode нам не особо интересен, он предполагает, что мы меняем ВСЕ ключи. Кому интересно (эт для жестких параноиков), прошу сюда, не советую читать неподкованным в теме и слабонервных.. Там жестяк.
Audit Mode и Deployed Mode - режимы, которые практически неподвластны пользователю.
User Mode наш вариант, он позволяет добавлять\удалять пользовательские ключи MOK (Machine Owner Keys). Вот этот режим и рассмотрим внимательней ниже.
Есть несколько абсолютно разных по уровню доступа ключей SecureBoot - PK, KEK, DB, DBX, MOK. Подробнее читайте здесь..
Мы будем добавлять свои ключи в MOK лист в режиме User Mode. Мы не будем претендовать на какие-то глобальные изменения, просто "попросим" систему временно принять ключ или несколько - он\они пропишутся в NVRAM. Возможно немного сложно в теории, но на практике это просто, смотрим на видео ниже.

Shim и MOKManager.

Shim - это промежуточный загрузчик, подписанный валидным ключем от MS, задача которого разрешать к загрузке файлы, которые подписаны каким-нибудь ключем и этот ключ добавлен в MOK лист. Строго говоря подпись необязательна, файл может быть добавлен в MOK лист и по хэшу.
Дополнительная функция его - запускать MOKManager при ошибке. В данном случае ошибкой будет считаться, если файл grubx64.efi не прошел проверку, то есть в MOK листе о нём никаких сведений нет. Сам MOKManager не всегда добавляется в дистрибутив Linux, но его легко найти\докачать при желании. Также не догма, что загрузчик должен называться grubx64.efi, встречал разные варианты, впрочем чаще всего именно grubx64.efi ибо Shim исторически был создан и заточен под grub2.
Некоторая инфа есть здесь, впрочем кое-что уже устарело... Скачать.

Ключи или хэш?

Задача MOKManager проста - добавить в базу MOK ключи или хэши нужных бинарников EFI. Это могут быть драйвера, лоадеры, ядра, шеллы, утилиты и т.п.
Есть две возможности. Добавить ключи или добавить хэши. Если нужный бинарник подписан, то имхо удобнее добавить ключ, если не подписан, то придется добавлять хэш.
К примеру rEFInd имеет 7 драйверов x64 плюс сам rEFInd плюс несколько утилит. Согласитесь, что проще для всего этого зоопарка добавить один ключ, который автор заботливо нам предоставил, нежели 10 хэшей.
Что делать, если бинарник не подписан цифровой подписью? Тут два варианта. Подписать бинарник самому и потом добавить ключ или добавить хэш. Если бинарник один, два конечно хэш проще, а если 70?
Иногда бывает, что бинарник подписан, но публичного ключа автор не предоставил. Это не беда, можно экспортировать ключ в любой ОС. Пример экспорта ключа из Windows.

PRELoader и HashTool.

PRELoader - это промежуточный загрузчик, подписанный валидным ключем от MS, задача которого разрешать к загрузке файлы, которые имеют хэш в MOK листе. Он чем-то похож на Shim, но работает мне кажется немного не так, впрочем я не великий спец и нюансы мне неясны. Имхо он более прост и возможно надежнее, чем Shim.
Дополнительная функция его - запускать HashTool при ошибке. В данном случае ошибкой будет считаться, если файл Loader.efi не прошел проверку, то есть в MOK листе о нём никаких сведений нет. HashTool тоже подписан валидным ключем от MS и это его принципиальное отличие от MOKManager. Задача HashTool - добавить в базу MOK хэши нужных бинарников EFI.
Некоторая инфа есть здесь... Скачать.
Все перечисленные примеры 1 (Shim + MokManager), 2 (непоказанный по лени, но по факту тоже Shim + MokManager) и 3 (PRELoader+HashTool) УЖЕ НЕАКТУЛЬНЫ. Оставлены для истории.. Рекомендую использовать пример 4.
Пример номер 1.
Есть всем известный бутлоадер rEFInd. Задача - запустить его в SecureBoot режиме.
Действуем просто. Добавляем к rEFInd Shim + MokManager, я взял из Ubuntu. Ссылка для загрузки, в архиве rEFInd, readme.txt c описанием и видеофайл. Ниже GIF ...

Вроде всё прекрасно, rEFInd великолепен. Но у rEFInd есть один недостаток. Он впадает в ступор, если через него пробовать загрузить другой Shim. То есть к примеру загрузка по схеме Shim -> rEFInd -> Shim -> grub2 не работает. И это печально, ведь может быть Android, Linux, etc. Я не поленился и спросил автора как быть в этой ситуации, он мне посоветовал добавлять ключи или хэши в MOK и тем самым исключать второй Shim из цепочки загрузки. Но это не всегда приемлемо, после обновления всё может пойти прахом.. Поэтому ниже другой вариант.
Пример номер 2.
Пока не готово видео, будет готово - выложу.
Пример номер 3.
Многие знают что такое Kon-Boot, на офсайте написано, что он не поддерживает SecureBoot. Попробуем исправить это безобразие с помощью PRELoader. Ссылка для загрузки, в архиве Kon-Boot, readme.txt c описанием и видеофайл. Ниже GIF ...

Пример номер 4.
ValdikSS сделал всем отличный подарок. Его модифицированный PRELoader грузит все подряд с отсутствующей или недоверенной подписью. Мой комплект немного изменен по сравнению с оригиналом, но плюшки остались ;) Основной бут менеджер заменен на rEFInd и добавлены BootIt UEFI, Scripts Menu TBOSDT, Image for Linux GUI (NET) и Kon-Boot. Ссылка для загрузки, в архиве readme.txt c описанием и видеофайл. Ниже GIF ...


Последний раз редактировалось: dialmak (2019-03-11 22:14), всего редактировалось 62 раз(а)

[Цитировать]

    dialmak
  • 2607
  • Стаж: 8 лет 1 месяц
  • Сообщений: 842
  • Репутация:40

    [+] [-]
Итак.
Если я\мы сможем разобраться в чем-то, то может мы и сможем влиять на это?
Давайте для начала разберемся что такое SecureBoot в практическом смысле. По тупому это означает, что НИКТО КРОМЕ MS не сможет загрузить ничего. НО. Как практика показывает это не совсем так, ведь грузится и ubuntu и fedora как правило без всяких проблем.
А вот тут мы приходим к пониманию, что есть все таки какая-то щель\метод\принцип обхода SecureBoot иначе никак бы не получилось загрузить ubuntu\fedora\etc..
Исторически сложилось 2 метода обхода SecureBoot - это Shim или PRELoader. Оба метода благословила MS в разное время, но распространение они получили в жизни разное.
В данный момент Shim более распространен и именно через него мы и будем действовать.
Это не означает, что нельзя действовать по методу PRELoader, просто через Shim как правило больше вариантов и он более распространен.

[Цитировать]

    dialmak
  • 2607
  • Стаж: 8 лет 1 месяц
  • Сообщений: 842
  • Репутация:40

    [+] [-]
Итак Shim.
По простому - это промежуточный загрузчик, задача которого просто "показать и сказать" системе, что мол все путём, не парься "пацаны свои"..
Дополнительная функция его - ДОБАВИТЬ в "свои пацаны" другой загрузчик через MOKManager.
В общем это не рекламируется и сам MOKManager редко добавляется в дистрибутив, но его легко найти при желании.


Последний раз редактировалось: dialmak (2018-10-21 12:37), всего редактировалось 1 раз

[Цитировать]

    gera_serg
  • 1171
  • Стаж: 8 лет 8 месяцев
  • Сообщений: 1421
  • Репутация:9

    [+] [-]
58485По тупому это означает, что НИКТО КРОМЕ MS не сможет загрузить ничего. НО.
Ну вот допустим попалась какая-то очень кривая по биосу (без отключения SB) конфигурация
- РE x64 ядра и софт загрузятся
- IFL загрузится
- KRD загрузится
- ...
Ради чего практического искать щель обхода - хотелось бы услышать подетальнее.
Без вариантов - вот нужна эта "щель" и всё...

[Цитировать]

    dialmak
  • 2607
  • Стаж: 8 лет 1 месяц
  • Сообщений: 842
  • Репутация:40

    [+] [-]
gera_serg, Ну если загрузилось всё, значит кто-то уже посодействовал..
Я не хотел вникать и писать на эту тему, но ладно, чуток напишу..
Суть в том, что если что-то КРОМЕ MS загрузился в режиме SecureBoot, то это означает одно из двух.
Или был Shim или был PRELoader. Это типа..
- IFL загрузится
- KRD загрузится
Но я видел несколько вариантов загрузки и без Shim\PRELoader и не MS, но это редкое исключение, типа данная прога глобальна и важна, очень важна, например это известный всем тест памяти.
Что касается практически - ну мне нужно снять видео и показать, дайте время, завтра покажу..

[Цитировать]

    dialmak
  • 2607
  • Стаж: 8 лет 1 месяц
  • Сообщений: 842
  • Репутация:40

    [+] [-]
Так. В общем gera_serg хоть и задал странный вопрос, но он подсказал мне как показать сертификаты.
А теперь давайте посмотрим ПОЧЕМУ же грузится всем известный тест памяти без всяких проблем в любом режиме? А ведь прога не от MS.. Дык пацаны получили сертификат от MS, как то так.. Почему получили я не знаю, скорее всего потому что прога глобальна и важна..
Что же имеет всем знакомый rEFInd? Не получил ничего от MS, юзает свой сертификат
А вот и первый пострадавший. Известный всем бутлоадер rEFInd НЕ РАБОТАЕТ в SecureBoot.
Ну вот и будем исправлять это недоразумение. Завтра..

[Цитировать]

    stea.61
  • 2490
  • Стаж: 8 лет 2 месяца
  • Сообщений: 656
  • Репутация:67

    [+] [-]
  • Откуда: 61 RUS
58474Тема нужная ...
Абсолютно согласен с этим.
Есть вот только сомнения в ее "бесценности" по причине авторства топика (в том числе и на основании прошлого опыта общения) - уж очень много менторского тона и набивания цены себе любимому...
При том, что с первых же постов видны неточности:
58488я видел несколько вариантов загрузки и без Shim\PRELoader и не MS, но это редкое исключение, типа данная прога глобальна и важна, очень важна, например это известный всем тест памяти
Решил высказать здесь эти свои сомнения, т.к., имхо, недостоверная или неточная информация хуже, чем отсутствие таковой.


Последний раз редактировалось: stea.61 (2018-10-20 11:23), всего редактировалось 2 раз(а)

[Цитировать]

    stea.61
  • 2490
  • Стаж: 8 лет 2 месяца
  • Сообщений: 656
  • Репутация:67

    [+] [-]
  • Откуда: 61 RUS
Если уж речь про "известный всем" тест памяти, то он то как раз от MS

[Цитировать]

    gera_serg
  • 1171
  • Стаж: 8 лет 8 месяцев
  • Сообщений: 1421
  • Репутация:9

    [+] [-]
симпатичная картинка к теме

[Цитировать]

    dialmak
  • 2607
  • Стаж: 8 лет 1 месяц
  • Сообщений: 842
  • Репутация:40

    [+] [-]
stea.61,
Если уж речь про "известный всем" тест памяти, то он то как раз от MS
Нет, речь шла про https://www.memtest86.com/
по причине авторства топика
ну не читайте, я не заставляю

[Цитировать]

    dialmak
  • 2607
  • Стаж: 8 лет 1 месяц
  • Сообщений: 842
  • Репутация:40

    [+] [-]
gera_serg, Есть такие. Как правило это x32 UEFI и SecureBoot у них находится в режиме Deployed Mode. Так для них и MOKManager-а нет подписанного в природе ибо он там бесполезен. Впрочем такие устройства уже вымерли, их единицы.
Есть планшеты\ноуты x64 UEFI c однократным отключением SecureBoot, есть с неотключаемым, кто как хочет, так и .. делает.
В перспективе угрожают, что возможности отключить SecureBoot не будет в принципе. Поживем - увидим.
coka, Никто не запрещает и на чужих, я просто написал, что мне не доводилось пока это делать.
Впрочем соврал, вспомнил. Один раз делал, добавлял ключ Terabyte для Image for UEFI на ноуте DELL. Там получилась странная ситуация. BootIt UEFI имеет Shim, но он работал почему-то частично. Для самого BootIt UEFI он работал, а при вызове Image for UEFI и TBOSDT не работал. Я почесал репу, хотел обновить BIOS, но плюнул и добавил ключ Terabyte, начало работать всё.

[Цитировать]

    dialmak
  • 2607
  • Стаж: 8 лет 1 месяц
  • Сообщений: 842
  • Репутация:40

    [+] [-]
ALL
Вспомнил ещё одну утилиту, которую благосклонно подписал MS и поэтому она не требует Shim\PREloader, это wimboot, скриншот.
Жаль, что iPXE не удосужился такой чести.

[Цитировать]

    dialmak
  • 2607
  • Стаж: 8 лет 1 месяц
  • Сообщений: 842
  • Репутация:40

    [+] [-]
Shim и MOKManager отдельно без других файлов.
PRELoader и HashTool отдельно без других файлов.

[Цитировать]

    dialmak
  • 2607
  • Стаж: 8 лет 1 месяц
  • Сообщений: 842
  • Репутация:40

    [+] [-]
https://usbtor.ru/viewtopic.php?p=59110#59110
maanu,
i can not use shim+MokManager, it does not work on my flex 4 , either in Secure or non-secure boot.
Ок. У меня 2 вопроса.
1. Работает ли Shim+MokManager при отключенном SecureBoot?
2. Есть ли у вас на ноутбуке режим CSM для Legacy? Если есть , то отключаете ли вы CSM при включении SecureBoot?
Дело в том, что отключение CSM является обязательным условием для нормальной работы SecureBoot.
Если не работает Shim+MokManager, значит нельзя установить Ubuntu в режиме EFI. Я сильно сомневаюсь в этом..

[Цитировать]

    dialmak
  • 2607
  • Стаж: 8 лет 1 месяц
  • Сообщений: 842
  • Репутация:40

    [+] [-]
Можете также попробовать вариант поновее:
- Shim_MokManager_rEFInd, подписан Ubuntu
или
- Shim_MokManager_rEFInd_fallback, подписан Ubuntu
или
- Shim_MokManager_rEFInd, подписан Fedora
Shim_MokManager_rEFInd_fallback автоматически добавляет пункт rEFInd в меню NVRAM.
Последний на некоторых ноутбуках при включенном SecureBoot не загрузится, если в MOK не добавлен сертификат Fedora.

Страница 1 из 3


Показать сообщения:    

Текущее время: 28-Мар 13:43

Часовой пояс: UTC + 3


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