Различия
Здесь показаны различия между двумя версиями данной страницы.
Предыдущая версия справа и слева Предыдущая версия Следующая версия | Предыдущая версия Следующая версия Следующая версия справа и слева | ||
wiki:uefi [2019/03/21 18:39] [Возврат в режим Setup] |
wiki:uefi [2019/10/13 03:09] [Загрузка ядра Linux непосредственно из UEFI] |
||
---|---|---|---|
Строка 446: | Строка 446: | ||
<code>bcfg driver add 0 EFI\drivers\ext2_x64.efi "EXT2-4 Driver"</code> | <code>bcfg driver add 0 EFI\drivers\ext2_x64.efi "EXT2-4 Driver"</code> | ||
- | Все замечательно и этот драйвер, при каждом запуске системы, будет загружаться во время инициализации UEFI автоматически, но ремапинга не будет. Для того, что бы после загрузки драйвера инициировать ремапинг нужно в опции загрузки драйвера указать специальный атрибут LOAD_OPTION_FORCE_RECONNECT, однако ни одной командой UEFI-Shell или опцией efibootmgr этот атрибут не установить (по крайней мере мне не удалось найти такой команды). Перелопатив спецификацию UEFI можно понять, что нужно то всего прописать значение 3 вместо 1 в первом 32-битном слове UEFI переменной отвечающей за загрузку драйвера (той самой Driver0000, что мы создали командой bcfg или efibootmgr). Сделать это изменение можно любым HEX редактором (из загруженной системы), запущенным с правами рута, в котором на редактирование открывается файл /sys/firmware/efi/efivars/Driver0000-8be4df61-93ca-11d2-aa0d-00e098032b8c (это маппинг в файловую систему sys переменной UEFI). В редакторе нужно 5-й байт от начала поменять с значения 01 на 03 и сохранить файл. | + | Все замечательно и этот драйвер, при каждом запуске системы, будет загружаться во время инициализации UEFI автоматически, но ремапинга не будет. Для того, чтобы после загрузки драйвера инициировать ремапинг нужно в опции загрузки драйвера указать специальный атрибут LOAD_OPTION_FORCE_RECONNECT, однако ни одной командой UEFI-Shell или опцией efibootmgr этот атрибут не установить (по крайней мере мне не удалось найти такой команды). Перелопатив спецификацию UEFI можно понять, что нужно то всего прописать значение 3 вместо 1 в первом 32-битном слове UEFI переменной отвечающей за загрузку драйвера (той самой Driver0000, что мы создали командой bcfg или efibootmgr). Сделать это изменение можно любым HEX редактором (из загруженной системы), запущенным с правами рута, в котором на редактирование открывается файл /sys/firmware/efi/efivars/Driver0000-8be4df61-93ca-11d2-aa0d-00e098032b8c (это маппинг в файловую систему sys переменной UEFI). В редакторе нужно 5-й байт от начала поменять с значения 01 на 03 и сохранить файл. |
<note important>После серии окирпиченных патчем Бармина машин (см. ниже эту замечательную историю) все UEFI переменные теперь защищены от изменений специальным атрибутом. Снять его перед редактированием можно командой chattr -i от рута. | <note important>После серии окирпиченных патчем Бармина машин (см. ниже эту замечательную историю) все UEFI переменные теперь защищены от изменений специальным атрибутом. Снять его перед редактированием можно командой chattr -i от рута. | ||
Хорошим тоном будет вернуть защиту после редактирования командой chattr +i </note> | Хорошим тоном будет вернуть защиту после редактирования командой chattr +i </note> | ||
- | <note important>Я конечно понимаю, что такой хакерский метод - это уже просто за гранью разумного для большинства пользователей UBUNTU, но пока мне не удалось найти другого пути задать атрибут LOAD_OPTION_FORCE_RECONNECT в опции загрузки драйвера((Поэтому я завел [[https://github.com/rhboot/efibootmgr/issues/108|ишью на гитхабе]] с просьбой автору efibootmgr реализовать эту возможность)). </note> | + | <note important>Я конечно понимаю, что такой хакерский метод - это уже просто за гранью разумного для большинства пользователей UBUNTU, но пока мне не удалось найти другого пути задать атрибут LOAD_OPTION_FORCE_RECONNECT в опции загрузки драйвера. Поэтому я завел [[https://github.com/rhboot/efibootmgr/issues/108|ишью на гитхабе]] с просьбой авторам efibootmgr реализовать эту возможность. Позднее я даже оформил [[https://github.com/rhboot/efibootmgr/pull/109|PR]] (Pull Request) с реализацией этой возможности. Однако это PR добавили в мастер ветку только 7 месяцев спустя. И, видимо, эта новая возможность efibootmgr появится в версии 17. |
+ | </note> | ||
После нашей хакерской атаки на UEFI 8-) можно перегрузиться в UEFI-Shell и там прямо при запуске увидеть, что все EXT4 разделы уже отмаплены в FS<n> "диски", а значит на них можно сослаться при задании команды загрузки для опции загрузки ОС. | После нашей хакерской атаки на UEFI 8-) можно перегрузиться в UEFI-Shell и там прямо при запуске увидеть, что все EXT4 разделы уже отмаплены в FS<n> "диски", а значит на них можно сослаться при задании команды загрузки для опции загрузки ОС. | ||
Строка 480: | Строка 481: | ||
<note important>Загрузка, организованная одним из вышеописанных способов, не требует наличия загрузчика (GRUB и Shim можно и нужно удалить из системы), ведь мы передаем UEFI все функции загрузчика ОС. | <note important>Загрузка, организованная одним из вышеописанных способов, не требует наличия загрузчика (GRUB и Shim можно и нужно удалить из системы), ведь мы передаем UEFI все функции загрузчика ОС. | ||
- | Устранение из процесса загрузки загрузчиков (оригинально это цепочка из двух: shim + GRUB) заметно (но не так что бы очень значительно) сокращает время загрузки ОС. Вот как это выглядит в цифрах на примере моего свежего mini-pc (I5 5257U, 8Gb RAM, SSD): утилита systemd-analyze сообщает, что на стадию работы загрузчиков в случае цепочки UEFI-Shim-GRUB-Kernel требуется чуть меньше секунды - 967ms, а на прямую загрузку UEFI-Kernel - 153ms. При полной (холодной) загрузке системы за ~14 секунд выигрыш составляет порядка 6%.</note> | + | Устранение из процесса загрузки загрузчиков (оригинально это цепочка из двух: shim + GRUB) заметно (но не так что бы очень значительно) сокращает время загрузки ОС. Вот как это выглядит в цифрах на примере одного mini-pc (I5 5257U, 8Gb RAM, SSD): утилита systemd-analyze сообщает, что на стадию работы загрузчиков в случае цепочки UEFI-Shim-GRUB-Kernel требуется чуть меньше секунды - 967ms, а на прямую загрузку UEFI-Kernel - 153ms. При полной (холодной) загрузке системы за ~14 секунд выигрыш составляет порядка 6%.</note> |
===== Полезные утилиты для UEFI ===== | ===== Полезные утилиты для UEFI ===== | ||
В стандартных репозиториях Ubuntu есть несколько полезных пакетов с утилитами для работы с настройками UEFI. | В стандартных репозиториях Ubuntu есть несколько полезных пакетов с утилитами для работы с настройками UEFI. | ||
- | * efibootmgr - утилита, которой можно менять настройки загрузки UEFI, в частности: настраивать приоритет загрузки, создавать/изменять/удалять загрузочные записи UEFI. | + | * **efibootmgr** - утилита, которой можно менять настройки загрузки UEFI, в частности: настраивать приоритет загрузки, создавать/изменять/удалять загрузочные записи UEFI. |
- | * efivar - простая утилита для работы с переменными UEFI. | + | * **efivar** - простая утилита для работы с переменными UEFI. |
- | * efitool - набор утилит и efi-приложений для работы с ключами/сертификатами, используемыми при загрузке в режиме Secure Boot. | + | * **efitool** - набор утилит и efi-приложений для работы с ключами/сертификатами, используемыми при загрузке в режиме Secure Boot. |
- | * sbsigntool - утилиты для подписывания и проверки подписей UEFI-приложений, для организации загрузки в Secure Boot режиме. | + | * **sbsigntool** - утилиты для подписывания и проверки подписей UEFI-приложений, для организации загрузки в Secure Boot режиме. |
У всех этих утилит есть вполне толковые man-руководства и есть примеры использованию в Интернете, поэтому я не стану останавливаться на деталях использования этих утилит. | У всех этих утилит есть вполне толковые man-руководства и есть примеры использованию в Интернете, поэтому я не стану останавливаться на деталях использования этих утилит. | ||
Строка 505: | Строка 506: | ||
Самое же примечательное в этой ситуации ИМХО в том, что 20 лет назад отпущенная шутка, до сих пор стреляет, да еще с невиданной доселе мощью. 8-) | Самое же примечательное в этой ситуации ИМХО в том, что 20 лет назад отпущенная шутка, до сих пор стреляет, да еще с невиданной доселе мощью. 8-) | ||
+ | <note>Т.е. если раньше патч успешно уничтожал ОС на компьютере, то теперь стало возможным еще и вывести из строя компьютер (при кривой реализации UEFI).</note> | ||
Строка 511: | Строка 513: | ||
[[https://ru.wikipedia.org/wiki/Extensible_Firmware_Interface|Википедия о UEFI]] \\ | [[https://ru.wikipedia.org/wiki/Extensible_Firmware_Interface|Википедия о UEFI]] \\ | ||
[[https://ru.wikipedia.org/wiki/%D0%A2%D0%B0%D0%B1%D0%BB%D0%B8%D1%86%D0%B0_%D1%80%D0%B0%D0%B7%D0%B4%D0%B5%D0%BB%D0%BE%D0%B2_GUID|Википедия о GPT]]\\ | [[https://ru.wikipedia.org/wiki/%D0%A2%D0%B0%D0%B1%D0%BB%D0%B8%D1%86%D0%B0_%D1%80%D0%B0%D0%B7%D0%B4%D0%B5%D0%BB%D0%BE%D0%B2_GUID|Википедия о GPT]]\\ | ||
- | [[https://wiki.archlinux.org/index.php/Unified_Extensible_Firmware_Interface_(%D0%A0%D1%83%D1%81%D1%81%D0%BA%D0%B8%D0%B9)|Очень подробная Wiki по UEFI (к сожалению не полностью переведенная на русский язык)]] | + | [[https://wiki.archlinux.org/index.php/Unified_Extensible_Firmware_Interface_(%D0%A0%D1%83%D1%81%D1%81%D0%BA%D0%B8%D0%B9)|Очень подробная Wiki по UEFI]] (к сожалению не полностью переведенная на русский язык)\\ |
- | [[https://habrahabr.ru/post/267953/|Очень толковая статья о SecureBoot и методах борьбы с ним. | + | [[https://habrahabr.ru/post/267953/|Очень толковая статья о SecureBoot и методах борьбы с ним.]] |
{{tag>uefi boot}} | {{tag>uefi boot}} | ||