Различия
Здесь показаны различия между двумя версиями данной страницы.
Предыдущая версия справа и слева Предыдущая версия Следующая версия | Предыдущая версия | ||
wiki:uefi [2019/03/21 18:17] [Что нужно для того что бы ОС грузилась через BIOS?] |
wiki:uefi [2020/07/31 18:17] (текущий) [Что нужно для того что бы ОС грузилась через BIOS?] |
||
---|---|---|---|
Строка 15: | Строка 15: | ||
Проблемой BIOS принято считать то, что много работы он делает зря (чем затягивает процесс загрузки системы). Практически всю его работу по инициализации и поддержке оборудования компьютера все современные ОС попросту игнорируют и повторно инициализируют и далее работают через свои драйвера. Все, что дает BIOS, было реально востребовано только в ранних версиях DOS... | Проблемой BIOS принято считать то, что много работы он делает зря (чем затягивает процесс загрузки системы). Практически всю его работу по инициализации и поддержке оборудования компьютера все современные ОС попросту игнорируют и повторно инициализируют и далее работают через свои драйвера. Все, что дает BIOS, было реально востребовано только в ранних версиях DOS... | ||
- | Другой проблемой являются ограничения, которые установлены для поддержки BIOS: это 16-ти разрядный реальный режим работы процессора с набором команд i8086, 1Мб адресуемого пространства памяти и периферия (клавиатура, видео адаптер, контроллер прямого доступа в память) совместимая с IBM AT. На сегодняшний день, требовать от 64-х разрядного многоядерного, многопоточного процессора совместимости с одноядерным и однопоточным 16-разрядным i8086 - уже немного смешно, а требование совместимости по периферии с IBM PC-AT(компьютер 1984-го года выпуска) уже даже не смешно, а очень грустно. | + | Другой проблемой являются ограничения, которые установлены для поддержки BIOS: это 16-разрядный реальный режим работы процессора с набором команд i8086, 1Мб адресуемого пространства памяти и периферия (клавиатура, видео адаптер, контроллер прямого доступа в память) совместимая с IBM AT. На сегодняшний день, требовать от 64-х разрядного многоядерного, многопоточного процессора совместимости с одноядерным и однопоточным 16-разрядным i8086 - уже немного смешно, а требование совместимости по периферии с IBM PC-AT(компьютер 1984-го года выпуска) уже даже не смешно, а очень грустно. |
==== (U)EFI ==== | ==== (U)EFI ==== | ||
Идеи отказаться от всего того ненужного, что делает BIOS, снять архаичные ограничения BIOS и сделать процесс инициализации и загрузки более гибким возникали уже очень давно, и различные попытки сделать это предпринимались, но IT-индустрия реально созрела к принятию нового общего стандарта загрузки персональных компьютеров только в начале этого века. В 2005 был создан консорциуму [[http://www.uefi.org/|UEFI Forum]], которому INTEL передал свою наработки по проекту Intel Boot Initiative (позже переименованному в EFI - Extensible Firmware Interface), начатому еще середине 90-х. Помимо Intel в консорциум вошли AMD, Apple, IBM, Microsoft и многие другие крупные IT-компании. Вместе с созданием консорциума спецификация EFI была переименована в UEFI (Unified Extensible Firmware Interface)((Не смущайтесь тем, что во многих местах UEFI упоминается как EFI - по сути это не совсем правильно, но по факту - речь об одном и том же.)). | Идеи отказаться от всего того ненужного, что делает BIOS, снять архаичные ограничения BIOS и сделать процесс инициализации и загрузки более гибким возникали уже очень давно, и различные попытки сделать это предпринимались, но IT-индустрия реально созрела к принятию нового общего стандарта загрузки персональных компьютеров только в начале этого века. В 2005 был создан консорциуму [[http://www.uefi.org/|UEFI Forum]], которому INTEL передал свою наработки по проекту Intel Boot Initiative (позже переименованному в EFI - Extensible Firmware Interface), начатому еще середине 90-х. Помимо Intel в консорциум вошли AMD, Apple, IBM, Microsoft и многие другие крупные IT-компании. Вместе с созданием консорциума спецификация EFI была переименована в UEFI (Unified Extensible Firmware Interface)((Не смущайтесь тем, что во многих местах UEFI упоминается как EFI - по сути это не совсем правильно, но по факту - речь об одном и том же.)). | ||
- | Основные концепции положенные в основу UEFI - "минималистичность", "модульность" и поддержка разных процессоров. Прошивка UEFI может быть собрана под 32-битный или 64-битный процессоры Intel, 32-х или 64-х битный ARM процессор, а также для Intel Itanium процессоров. Кроме того, UEFI имеет собственный менеджер загрузки и умеет работать с файловыми системами на диске (по умолчанию только FAT32), а также умеет загружать драйвера для поддержки различного оборудования и любых файловых систем.\\ | + | Основные концепции положенные в основу UEFI - "минималистичность", "модульность" и поддержка разных процессоров. Прошивка UEFI может быть собрана под 32-битный или 64-битный процессоры Intel, 32- или 64-битный процессор ARM, а также для процессоров Intel Itanium. Кроме того UEFI имеет собственный менеджер загрузки и умеет работать с файловыми системами на диске (по умолчанию только FAT32), а также умеет загружать драйверы для поддержки различного оборудования и любых файловых систем.\\ |
После включения компьютера и проведения первичного теста оборудования (на этом этапе разницы с BIOS нет) инициализируются только те подсистемы, которые необходимые для загрузки. | После включения компьютера и проведения первичного теста оборудования (на этом этапе разницы с BIOS нет) инициализируются только те подсистемы, которые необходимые для загрузки. | ||
- | В некоторых режимах загрузки, которые обычно называют Fast-boot (или Fast-Startup) даже клавиатура может оставаться не инициализированной пока не загрузится ОС. Некоторые настройки Fast-boot могут отключать работу со всеми USB устройствами и не будет возможности даже выбрать с чего грузится компьютеру, ведь клавиатура не работает до тех пор, пока не загрузится ОС. | + | В некоторых режимах загрузки, которые обычно называют Fast-boot (или Fast-Startup), даже клавиатура может оставаться не инициализированной, пока не загрузится ОС. Некоторые настройки Fast-boot могут отключать работу со всеми USB устройствами и не будет возможности даже выбрать с чего грузиться компьютеру, ведь клавиатура не работает до тех пор, пока не загрузится ОС. |
- | Причем, в отличии от BIOS, все компоненты которого записаны в постоянную(флеш) память, UEFI может хранить часть своего кода на диске - в специальном разделе ESP((на самом деле ESP раздел может быть и на флеш-памяти и даже на сетевом хранилище, но эта экзотика (предусмотренная стандартом) вряд ли будет востребована простыми пользователями)). Это позволяет легко расширять, менять и обновлять код поддерживающий различные устройства компьютера без необходимости перепрограммировать постоянное ЗУ компьютера. А кроме драйверов для поддержки устройств на ESP разделе может хранится и поддержка протоколов, утилиты и даже собственная EFI-оболочка (shell), из-под которой можно запускать собственные EFI-приложения. Т.е. UEFI по сути - маленькая ОС (или псевдо-ОС). При этом загрузчик операционной системы - становится обычным приложением, которое исполняется в окружении, предоставляемом псевдо-ОС UEFI. Подробнее о EFS разделе мы поговорим в главе [[https://help.ubuntu.ru/wiki/uefi#esp_%D1%80%D0%B0%D0%B7%D0%B4%D0%B5%D0%BB|ESP раздел]]. | + | Причем, в отличии от BIOS, все компоненты которого записаны в постоянную (флеш) память, UEFI может хранить часть своего кода на диске - в специальном разделе ESP((на самом деле ESP раздел может быть и во флеш-памяти и даже на сетевом хранилище, но эта экзотика (предусмотренная стандартом) вряд ли будет востребована простыми пользователями)). Это позволяет легко расширять, менять и обновлять код поддерживающий различные устройства компьютера без необходимости перепрограммировать постоянное ЗУ компьютера. А кроме драйверов для поддержки устройств на ESP разделе может хранится и поддержка протоколов, утилиты и даже собственная EFI-оболочка (shell), из-под которой можно запускать собственные EFI-приложения. Т.е. UEFI по сути - маленькая ОС (или псевдо-ОС). При этом загрузчик операционной системы становится обычным приложением, которое исполняется в окружении, предоставляемом псевдо-ОС UEFI. Подробнее о EFS разделе мы поговорим в главе [[https://help.ubuntu.ru/wiki/uefi#esp_%D1%80%D0%B0%D0%B7%D0%B4%D0%B5%D0%BB|ESP раздел]]. |
UEFI реализует свой менеджер загрузки, он поддерживает мульти-загрузку: позволяет выбирать загрузку из нескольких ОС и/или утилит. Загрузчик ОС - это просто efi-приложение, которое хранится на ESP разделе. В ESP может храниться много приложений, и пункты меню загрузки могут ссылаться каждый на свое приложение (или на одно, но с передачей разных параметров). Кроме того, UEFI поддерживает ассоциацию нажатия клавиш с пунктами загрузки (выбор пункта загрузки осуществляется в зависимости от того какая нажата клавиша в момент загрузки). Т.о. UEFI берет на себя большую часть задач, которые раньше могли решать только загрузчики ОС (типа GRUB). | UEFI реализует свой менеджер загрузки, он поддерживает мульти-загрузку: позволяет выбирать загрузку из нескольких ОС и/или утилит. Загрузчик ОС - это просто efi-приложение, которое хранится на ESP разделе. В ESP может храниться много приложений, и пункты меню загрузки могут ссылаться каждый на свое приложение (или на одно, но с передачей разных параметров). Кроме того, UEFI поддерживает ассоциацию нажатия клавиш с пунктами загрузки (выбор пункта загрузки осуществляется в зависимости от того какая нажата клавиша в момент загрузки). Т.о. UEFI берет на себя большую часть задач, которые раньше могли решать только загрузчики ОС (типа GRUB). | ||
Строка 31: | Строка 31: | ||
Архитектура UEFI позволяет также загрузить драйвера устройств (необходимые для работы ОС и для процедуры загрузки). Да и само ядро ОС можно загрузить (по крайней мере ядро Linux, собранное с опцией UEFISTUB) непосредственно из UEFI (т.е. устранить загрузчик из процесса загрузки). Такую возможность мы разберем более детально чуть позже в разделе [[https://help.ubuntu.ru/wiki/uefi#%D0%B7%D0%B0%D0%B3%D1%80%D1%83%D0%B7%D0%BA%D0%B0_%D1%8F%D0%B4%D1%80%D0%B0_linux_%D0%BD%D0%B5%D0%BF%D0%BE%D1%81%D1%80%D0%B5%D0%B4%D1%81%D1%82%D0%B2%D0%B5%D0%BD%D0%BD%D0%BE_%D0%B8%D0%B7_uefi|Загрузка ядра Linux непосредственно из UEFI]]. | Архитектура UEFI позволяет также загрузить драйвера устройств (необходимые для работы ОС и для процедуры загрузки). Да и само ядро ОС можно загрузить (по крайней мере ядро Linux, собранное с опцией UEFISTUB) непосредственно из UEFI (т.е. устранить загрузчик из процесса загрузки). Такую возможность мы разберем более детально чуть позже в разделе [[https://help.ubuntu.ru/wiki/uefi#%D0%B7%D0%B0%D0%B3%D1%80%D1%83%D0%B7%D0%BA%D0%B0_%D1%8F%D0%B4%D1%80%D0%B0_linux_%D0%BD%D0%B5%D0%BF%D0%BE%D1%81%D1%80%D0%B5%D0%B4%D1%81%D1%82%D0%B2%D0%B5%D0%BD%D0%BD%D0%BE_%D0%B8%D0%B7_uefi|Загрузка ядра Linux непосредственно из UEFI]]. | ||
- | Как и в случае с BIOS, UEFI - это стандарт, практической реализацией которого занимаются разные поставщики решений. Поэтому в реализации UEFI стандарта в прошивках разных поставщиков могут значительно отличаться (как визуально так и функциональным наполнением). Могут встречаться сильно урезанные по функционалу реализации (чаще в компьютерах выпущенных в 2000-х годах). Но базовые принципы работы UEFI в процессе загрузки различаться сильно не должны (он был определен и зафиксирован в самых ранних стандартах UEFI). Интерфейсы утилиты настройки могут сильно различаться, но значение имеет не способ оформления интерфейса, а те настройки, которые доступны для изменения через этот интерфейс. | + | Как и в случае с BIOS, UEFI - это стандарт, практической реализацией которого занимаются разные поставщики решений. Поэтому в реализации стандарта UEFI в прошивках разных поставщиков могут значительно отличаться (как визуально так и функциональным наполнением). Могут встречаться сильно урезанные по функционалу реализации (чаще в компьютерах выпущенных в 2000-х годах). Но базовые принципы работы UEFI в процессе загрузки различаться сильно не должны (он был определен и зафиксирован в самых ранних стандартах UEFI). Интерфейсы утилиты настройки могут сильно различаться, но значение имеет не способ оформления интерфейса, а те настройки, которые доступны для изменения через этот интерфейс. |
==== Совместимость ==== | ==== Совместимость ==== | ||
- | Само собой, современные прошивки умеют эмулировать работу BIOS. Отвечает за совместимость с BIOS модуль CSM (Compatibility Support Module иногда он еще называется Legasy support). Когда CSM включен и при загрузке загрузиться в UEFI не удалось, то CSM пытается найти загрузчик ОС в первом секторе диска (MBR) или в специальном служебном разделе (при GPT разбивке диска). Если код загрузчика найден, то CSM считает, что установлена ОС требующая поддержки BIOS режима, и прежде чем загрузить и запустить код из MBR, CSM проделывает все те же шаги инициализации оборудования, что предусмотрены для BIOS. | + | Само собой, современные прошивки умеют эмулировать работу BIOS. Отвечает за совместимость с BIOS модуль CSM (Compatibility Support Module иногда он еще называется Legasy support). Когда CSM включен и при загрузке загрузиться в UEFI не удалось, то CSM пытается найти загрузчик ОС в первом секторе диска (MBR) или в специальном служебном разделе (при GPT разбивке диска). Если код загрузчика найден, то CSM считает, что установлена ОС, требующая поддержки режима BIOS, и, прежде чем загрузить и запустить код из MBR, CSM проделывает все те же шаги инициализации оборудования, что предусмотрены для BIOS. |
Если вы планируете использовать только загрузку в варианте UEFI, то работу этого модуля лучше запретить в системной утилите вашей материнской платы (Firmware setup utility). Кроме того, загрузка в режиме SecureBoot (о ней будет рассказано ниже) явно требует, что бы работа модуля CSM была запрещена. | Если вы планируете использовать только загрузку в варианте UEFI, то работу этого модуля лучше запретить в системной утилите вашей материнской платы (Firmware setup utility). Кроме того, загрузка в режиме SecureBoot (о ней будет рассказано ниже) явно требует, что бы работа модуля CSM была запрещена. | ||
Строка 60: | Строка 60: | ||
<note>EFS раздел может быть также создан в таблице разделов формата ISO9660 (стандарт используемый для разметки CD/DVD оптических лисков). Это позволяет загружаться в режиме UEFI и с CD/DVD.</note> | <note>EFS раздел может быть также создан в таблице разделов формата ISO9660 (стандарт используемый для разметки CD/DVD оптических лисков). Это позволяет загружаться в режиме UEFI и с CD/DVD.</note> | ||
- | Получившаяся в результате "солянка" (из 4-х допустимых вариантов: UEFI + MBR, UEFI + GPT, BIOS/SCM + MBR и BIOS/SCM + GPT) создает некоторую путаницу и недопонимание. Давайте попробуем во всем этом разобраться более детально. | + | Получившаяся в результате "солянка" (из 4-х допустимых вариантов: UEFI + MBR, UEFI + GPT, BIOS/CSM + MBR и BIOS/CSM + GPT) создает некоторую путаницу и недопонимание. Давайте попробуем во всем этом разобраться более детально. |
===== Что нужно для того что бы ОС грузилась через BIOS? ===== | ===== Что нужно для того что бы ОС грузилась через BIOS? ===== | ||
<note>Несмотря на то, что загрузка в режиме BIOS уже не современна, не модна :-), а главное - технологически устарела, но, уверен, будет еще много сторонников этого пути, на протяжении долгих лет... Однако я не могу найти ни одного разумного довода использовать этот вариант если и ОС и компьютер поддерживают загрузку через UEFI.</note> | <note>Несмотря на то, что загрузка в режиме BIOS уже не современна, не модна :-), а главное - технологически устарела, но, уверен, будет еще много сторонников этого пути, на протяжении долгих лет... Однако я не могу найти ни одного разумного довода использовать этот вариант если и ОС и компьютер поддерживают загрузку через UEFI.</note> | ||
- | В первую очередь, для загрузки через BIOS, в утилите настройки вашего компьютера должна быть разрешена работа модуля CSM. Само собой, SecureBoot режим (о нем рассказано чуть ниже) в таком варианте организовать невозможно в принципе. | + | В первую очередь, для загрузки через BIOS, в утилите настройки вашего компьютера должна быть разрешена работа модуля CSM. Само собой, режим SecureBoot (о нем рассказано чуть ниже) в таком варианте организовать невозможно в принципе. |
- | Если разбивка диска - c таблицей разделов в MBR (вариант "BIOS/SCM + MBR"), то ничего дополнительно не нужно (это сочетание собственно и есть оригинальная конфигурация для варианта загрузки через BIOS). | + | Если разбивка диска - c таблицей разделов в MBR (вариант "BIOS/CSM + MBR"), то ничего дополнительно не нужно (это сочетание собственно и есть оригинальная конфигурация для варианта загрузки через BIOS). |
А вот если у вас диск размечен через GPT (вариант "BIOS/SCM + GPT"), то возникают некоторые сложности. \\ | А вот если у вас диск размечен через GPT (вариант "BIOS/SCM + GPT"), то возникают некоторые сложности. \\ | ||
Строка 73: | Строка 73: | ||
В процессе загрузки CSM модуль (эмулирующий работу BIOS) отвечает за то, что находит в GPT раздел BIOS-Boot, загружает первые 512 байт с этого раздела, и передает управление загруженному коду. За дальнейший процесс загрузки отвечает этот код, а CSM берет на себя задачу эмулировать обращение к секторам диска за MBR (вместо этих секторов производится подстановка секторов из раздела BIOS-Boot). | В процессе загрузки CSM модуль (эмулирующий работу BIOS) отвечает за то, что находит в GPT раздел BIOS-Boot, загружает первые 512 байт с этого раздела, и передает управление загруженному коду. За дальнейший процесс загрузки отвечает этот код, а CSM берет на себя задачу эмулировать обращение к секторам диска за MBR (вместо этих секторов производится подстановка секторов из раздела BIOS-Boot). | ||
- | <note>Пожалуй вот на этом и закончим обсуждать CSM и BIOS, все дальнейшее будет относится только к UEFI.</note> | + | ---- |
+ | |||
+ | Пожалуй вот на этом и закончим обсуждать CSM и BIOS, все дальнейшее будет относится только к UEFI. | ||
===== Что нужно для установки ОС, что бы она грузилась через UEFI? ===== | ===== Что нужно для установки ОС, что бы она грузилась через UEFI? ===== | ||
На самом деле все не так сложно как кажется. Как уже было сказано UEFI требует специального раздела ESP (с файловой системой FAT32 и флагами boot и esp). И, несмотря на то, что для этого раздела был предусмотрен специальный длинный идентификатор (UUID = C12A7328-F81F-11D2-BA4B-00A0C93EC93B) для GPT, который в таблицу разделов MBR ну никак не запихнешь, этому разделу дали еще и короткий идентификатор (EF), который можно "впихнуть" в таблицу разделов в MBR. Т.е. ESP раздел можно создать и на диске с GPT и на диске с таблицей разделов в MBR (однако такой вариант поддерживает не любая ОС). | На самом деле все не так сложно как кажется. Как уже было сказано UEFI требует специального раздела ESP (с файловой системой FAT32 и флагами boot и esp). И, несмотря на то, что для этого раздела был предусмотрен специальный длинный идентификатор (UUID = C12A7328-F81F-11D2-BA4B-00A0C93EC93B) для GPT, который в таблицу разделов MBR ну никак не запихнешь, этому разделу дали еще и короткий идентификатор (EF), который можно "впихнуть" в таблицу разделов в MBR. Т.е. ESP раздел можно создать и на диске с GPT и на диске с таблицей разделов в MBR (однако такой вариант поддерживает не любая ОС). | ||
Строка 94: | Строка 96: | ||
===== Менеджер загрузки UEFI ===== | ===== Менеджер загрузки UEFI ===== | ||
- | Кроме кода отвечающего за первичную инициализацию системы UEFI имеет свой менеджер загрузки. Работу менеджера загрузки задают переменные UEFI, хранящиеся в энергонезависимой памяти ((NVRAM - это та самая, для которой на материнской плате стоит батарейка, хотя в последнее время батарейка ставится только для часов реального времени, а энергонезависимую память обеспечивает флеш-память)). | + | Кроме кода отвечающего за первичную инициализацию системы UEFI имеет свой менеджер загрузки. Работу менеджера загрузки задают переменные UEFI, хранящиеся в энергонезависимой памяти NVRAM((это та самая, для которой на материнской плате стоит батарейка, хотя в последнее время батарейка чаще ставится только для часов реального времени, а энергонезависимую память обеспечивает флеш-память)). |
Переменные, которые задают работу менеджера загрузки это: | Переменные, которые задают работу менеджера загрузки это: | ||
Строка 111: | Строка 113: | ||
Переменные **Driver####** инициализируют загрузку UEFI драйверов. Переменная **DriverOrder** определяет последовательность загрузки драйверов. | Переменные **Driver####** инициализируют загрузку UEFI драйверов. Переменная **DriverOrder** определяет последовательность загрузки драйверов. | ||
- | Драйвера остаются в памяти после своей инициализации. Однако загруженные драйвера сразу не связываются с устройствами которые они обслуживают. Процесс такого связывания необходимо инициализировать отдельно. Но нужно отметить что происходит не просто связывание загруженных драйверов а повторное связывание, т.к. некоторые драйвера уже были связаны со своими устройствами в процессе первичной инициализации системы. За запуск процесса инициализации отвечает флаг LOAD_OPTION_FORCE_RECONNECT, который можно установить в поле атрибутов загрузочной записи **Driver####**. Если хоть у одного из загруженных драйверов этот флаг установлен, то после окончания загрузки всех драйверов менеджер загрузки UEFI инициализирует процедуру пере-связывания всех драйверов и устройств. | + | Драйвера остаются в памяти после своей инициализации. Однако загруженные драйвера сразу не связываются с устройствами, которые они обслуживают. Процесс такого связывания необходимо инициализировать отдельно. Но нужно отметить, что происходит не просто связывание загруженных драйверов, а повторное связывание, т.к. некоторые драйвера уже были связаны со своими устройствами в процессе первичной инициализации системы. За запуск процесса инициализации отвечает флаг LOAD_OPTION_FORCE_RECONNECT, который можно установить в поле атрибутов загрузочной записи **Driver####**. Если хоть у одного из загруженных драйверов этот флаг установлен, то после окончания загрузки всех драйверов менеджер загрузки UEFI инициализирует процедуру пере-связывания всех драйверов и устройств. |
Переменные **SysPrep####** инициализируют загрузку системных утилит. Переменная **SysPrepOrder** определяет последовательность утилит. Системных утилита должна выполнить свои действия и вернуть управление менеджеру загрузки UEFI. Утилиты не остаются в памяти, если нужен резидентный код, то его нужно загружать как **Driver####**. | Переменные **SysPrep####** инициализируют загрузку системных утилит. Переменная **SysPrepOrder** определяет последовательность утилит. Системных утилита должна выполнить свои действия и вернуть управление менеджеру загрузки UEFI. Утилиты не остаются в памяти, если нужен резидентный код, то его нужно загружать как **Driver####**. | ||
Строка 138: | Строка 140: | ||
Еще один способ изменения приоритета загрузки ОС - выбор записи **Boot####** по нажатию кнопки на клавиатуре в процессе загрузки. Для реализации такого механизма нужно привязать кнопку к записи **Boot####**. И если кнопка будет нажата, то менеджер загрузки пробует сначала загрузить запись **Boot####** привязанную к кнопке, и только если загрузить ОС по этой записи не удалось, то менеджер загрузки переходит к загрузке в соответствии с **BootOrder**. | Еще один способ изменения приоритета загрузки ОС - выбор записи **Boot####** по нажатию кнопки на клавиатуре в процессе загрузки. Для реализации такого механизма нужно привязать кнопку к записи **Boot####**. И если кнопка будет нажата, то менеджер загрузки пробует сначала загрузить запись **Boot####** привязанную к кнопке, и только если загрузить ОС по этой записи не удалось, то менеджер загрузки переходит к загрузке в соответствии с **BootOrder**. | ||
+ | |||
+ | Практически все функции и настройки менеджера загрузки UEFI позволяет настроить утилита **efibootmgr** (смотрите man efibootmgr что бы узнать как). | ||
---- | ---- | ||
Строка 143: | Строка 147: | ||
Вот такие серьезные возможности обеспечивает менеджер загрузки UEFI. Фактически в нем реализован весь функционал классических менеджеров загрузки ОС поддерживающих мультизагрузку (загрузку нескольких ос или нескольких версий одной ОС). Причем в вопросах восстановления функционал менеджера загрузки UEFI даже шире за счет того, что он реализуется в процессе инициализации системы. | Вот такие серьезные возможности обеспечивает менеджер загрузки UEFI. Фактически в нем реализован весь функционал классических менеджеров загрузки ОС поддерживающих мультизагрузку (загрузку нескольких ос или нескольких версий одной ОС). Причем в вопросах восстановления функционал менеджера загрузки UEFI даже шире за счет того, что он реализуется в процессе инициализации системы. | ||
- | Таким образом UEFI делает такие загрузчики (например GRUB) фактически ненужными. И ниже мы поговорим о том, как можно организовать загрузку ОС Linux из UEFI без дополнительных загрузчиков. | + | Таким образом UEFI делает такие загрузчики (например GRUB) фактически ненужными. И ниже мы поговорим о том, [[https://help.ubuntu.ru/wiki/uefi#%D0%B7%D0%B0%D0%B3%D1%80%D1%83%D0%B7%D0%BA%D0%B0_%D1%8F%D0%B4%D1%80%D0%B0_linux_%D0%BD%D0%B5%D0%BF%D0%BE%D1%81%D1%80%D0%B5%D0%B4%D1%81%D1%82%D0%B2%D0%B5%D0%BD%D0%BD%D0%BE_%D0%B8%D0%B7_uefi|как можно организовать загрузку ОС Linux из UEFI без дополнительных загрузчиков]]. |
===== Secure Boot ===== | ===== Secure Boot ===== | ||
Особого упоминания требует такая особенность UEFI как Secure Boot. | Особого упоминания требует такая особенность UEFI как Secure Boot. | ||
Строка 166: | Строка 170: | ||
<note warning>Обратите внимание: режим SecureBoot включается для всего компьютера, а это означает, что правильно подписанными должны быть все загрузчики (всех установленных ОС), утилиты и драйвера, которые загружаются с ESP раздела.</note> | <note warning>Обратите внимание: режим SecureBoot включается для всего компьютера, а это означает, что правильно подписанными должны быть все загрузчики (всех установленных ОС), утилиты и драйвера, которые загружаются с ESP раздела.</note> | ||
- | ===== Ключи системы Secure Boot ===== | + | ==== Ключи системы Secure Boot ==== |
На самом деле в энергонезависимой памяти компьютера (NVRAM) рассчитанного на работу с UEFI предусмотрено место не на один сертификат, более того, сертификаты хранятся в специально организованной, иерархической системе. Давайте рассмотри этот вопрос более детально, но начнем с того, что определим - что такое сами ключи, о которых мы тут говорим. | На самом деле в энергонезависимой памяти компьютера (NVRAM) рассчитанного на работу с UEFI предусмотрено место не на один сертификат, более того, сертификаты хранятся в специально организованной, иерархической системе. Давайте рассмотри этот вопрос более детально, но начнем с того, что определим - что такое сами ключи, о которых мы тут говорим. | ||
Строка 206: | Строка 210: | ||
Причем в ключи в db (dbt) могут добавляться и автоматически (если это предусмотрено конкретной реализацией UEFI): когда подпись загружаемого модуля не может быть проверена, то могут быть предусмотрены механизмы (поиск в массиве на диске или интерактивное подтверждение от авторизованного пользователя), которые разрешат добавить публичный ключ от подписи (подпись содержит публичный ключ для своей проверки) в db (или dbt). | Причем в ключи в db (dbt) могут добавляться и автоматически (если это предусмотрено конкретной реализацией UEFI): когда подпись загружаемого модуля не может быть проверена, то могут быть предусмотрены механизмы (поиск в массиве на диске или интерактивное подтверждение от авторизованного пользователя), которые разрешат добавить публичный ключ от подписи (подпись содержит публичный ключ для своей проверки) в db (или dbt). | ||
- | ===== Собственные ключи ===== | + | ==== Собственные ключи ==== |
Так как все ключи/сертификаты UEFI (PK, KEK, db) построены на основе открытых стандартов, то и весь набор этих ключей можно сформировать самостоятельно. Далее рассмотрим как это можно сделать, а вот [[https://habrahabr.ru/post/273497/|тут]] описано все тоже другим толковым автором. | Так как все ключи/сертификаты UEFI (PK, KEK, db) построены на основе открытых стандартов, то и весь набор этих ключей можно сформировать самостоятельно. Далее рассмотрим как это можно сделать, а вот [[https://habrahabr.ru/post/273497/|тут]] описано все тоже другим толковым автором. | ||
Строка 212: | Строка 216: | ||
Для работы нам потребуются утилита openssh (практически во всех дистрибутивах Linux эта утилита уже установлена) и утилиты из пакета efitools (доступна в репозиориях ubuntu((для установки выполните: sudo apt-get install efitools))). | Для работы нам потребуются утилита openssh (практически во всех дистрибутивах Linux эта утилита уже установлена) и утилиты из пакета efitools (доступна в репозиориях ubuntu((для установки выполните: sudo apt-get install efitools))). | ||
- | ==== Создание ключей ===== | + | === Создание ключей ==== |
Для начала создадим наш тестовый ключ и само-подписанный сертификат: | Для начала создадим наш тестовый ключ и само-подписанный сертификат: | ||
Строка 228: | Строка 232: | ||
c752155d-093f-4441-87c3-20e2352205ac</code> | c752155d-093f-4441-87c3-20e2352205ac</code> | ||
- | ==== Создание UEFI ключей ===== | + | === Создание UEFI ключей ==== |
Для того что бы установить наш ключ в базу ключей UEFI, нам потребуется специальны контейнер EFI_SIGNATURE_LIST, в котором будет задана переменная EFI_VARIABLE_AUTHENTICATION_2. Для упрощения, ключи в контейнере будут само-подписанными. | Для того что бы установить наш ключ в базу ключей UEFI, нам потребуется специальны контейнер EFI_SIGNATURE_LIST, в котором будет задана переменная EFI_VARIABLE_AUTHENTICATION_2. Для упрощения, ключи в контейнере будут само-подписанными. | ||
Строка 247: | Строка 251: | ||
Кроме того, все известные сертификаты от разработчиков linux (Canonical, Fedora, AltLinux, openSUSE и др.) - тоже само-подписанные, их вы можете найти в на сайте проекта [[http://www.rodsbooks.com/refind/|rEFInd]] или в проекте [[https://github.com/slytomcat/UEFI-Boot/tree/master/keys|UEFI-Boot на github]]</note> | Кроме того, все известные сертификаты от разработчиков linux (Canonical, Fedora, AltLinux, openSUSE и др.) - тоже само-подписанные, их вы можете найти в на сайте проекта [[http://www.rodsbooks.com/refind/|rEFInd]] или в проекте [[https://github.com/slytomcat/UEFI-Boot/tree/master/keys|UEFI-Boot на github]]</note> | ||
- | ==== Создание хранилища ключей ===== | + | === Создание хранилища ключей === |
Далее нам потребуется создать хранилище ключей в стандартном месте, где утилита sbkeysync будет их искать. | Далее нам потребуется создать хранилище ключей в стандартном месте, где утилита sbkeysync будет их искать. | ||
Строка 257: | Строка 261: | ||
На самом деле вы можете создать хранилище где угодно и указать утилите sbkeysync где оно находится в значении ключа --keystore. | На самом деле вы можете создать хранилище где угодно и указать утилите sbkeysync где оно находится в значении ключа --keystore. | ||
- | ==== Загрузка ключей ==== | + | === Загрузка ключей === |
- | === Через утилиту прошивки === | + | == Через утилиту прошивки == |
Загрузка ключей в UEFI может быть выполнена из утилиты настройки вашей материнской платы. Там нужно будет найти раздел (обычно Security) где задаются параметры SecureBoot. Возможно потребуется явно разрешить работу с ключами - выбрать режим управления ключами custom или как либо еще. | Загрузка ключей в UEFI может быть выполнена из утилиты настройки вашей материнской платы. Там нужно будет найти раздел (обычно Security) где задаются параметры SecureBoot. Возможно потребуется явно разрешить работу с ключами - выбрать режим управления ключами custom или как либо еще. | ||
Попав в окно утилиты по управлению ключами, первым делом сохраните (на всякий случай) фабричные ключи((Если ваша прошивка предоставляет опцию установки/восстановления фабричных ключей, то свою резервную копию фабричных ключей вам создавать не обязательно.)). После этого удалите все фабричные ключи, и по одному добавляйте ключи из вашего хранилища ключей (скорее всего, его придется перенести на ESP раздел, т.к. только этот раздел доступен для UEFI).\\ | Попав в окно утилиты по управлению ключами, первым делом сохраните (на всякий случай) фабричные ключи((Если ваша прошивка предоставляет опцию установки/восстановления фабричных ключей, то свою резервную копию фабричных ключей вам создавать не обязательно.)). После этого удалите все фабричные ключи, и по одному добавляйте ключи из вашего хранилища ключей (скорее всего, его придется перенести на ESP раздел, т.к. только этот раздел доступен для UEFI).\\ | ||
Строка 265: | Строка 269: | ||
Следует также отметить, что формат, в котором прошивка умеет загружать ключи может разниться в разных прошивках UEFI. Например прошивка AMI из недавно купленного мини-PC может взять сертификат и из подготовленного контейнера, и непосредственно из файла .pem. Т.о. вся эта возня со специальными контейнерами, в этом случае, вовсе не нужна: один и тот же само-подписанный сертификат можно загрузить и в PK, и в KEK, и в db. | Следует также отметить, что формат, в котором прошивка умеет загружать ключи может разниться в разных прошивках UEFI. Например прошивка AMI из недавно купленного мини-PC может взять сертификат и из подготовленного контейнера, и непосредственно из файла .pem. Т.о. вся эта возня со специальными контейнерами, в этом случае, вовсе не нужна: один и тот же само-подписанный сертификат можно загрузить и в PK, и в KEK, и в db. | ||
- | === Используя sbkeysync === | + | == Используя sbkeysync == |
Если UEFI находится в Setup режиме, то ключи можно загрузить и из ОС, используя утилиту sbkeysync. Но для начала воспользуйтесь опцией --dry-run, что бы убедится, что у вас все верно настроено и готово к этому важному процессу: | Если UEFI находится в Setup режиме, то ключи можно загрузить и из ОС, используя утилиту sbkeysync. Но для начала воспользуйтесь опцией --dry-run, что бы убедится, что у вас все верно настроено и готово к этому важному процессу: | ||
Строка 299: | Строка 303: | ||
<note important>Будьте предельно осторожны выполняя загрузку ключей, т.к. как только PK будет записан прошивка UEFI перейдет в режим User, а в некоторых прошивках это еще автоматом включит SecureBoot режим. Вы должны быть уверены, что прошивка UEFI позволит вам вернутся в Setup режим и/или удалить PK.</note> | <note important>Будьте предельно осторожны выполняя загрузку ключей, т.к. как только PK будет записан прошивка UEFI перейдет в режим User, а в некоторых прошивках это еще автоматом включит SecureBoot режим. Вы должны быть уверены, что прошивка UEFI позволит вам вернутся в Setup режим и/или удалить PK.</note> | ||
<note>Некоторые прошивки требуют перезагрузки для применения этих изменений в переменных UEFI. Прежде чем вы выполните перезагрузку, обязательно подпишите ваш загрузчик, иначе просто ничего не загрузится, ведь SecureBoot активирован и в db прописан ключ, которым будет проверяться подпись любого кода, который будет загружаться UEFI.</note> | <note>Некоторые прошивки требуют перезагрузки для применения этих изменений в переменных UEFI. Прежде чем вы выполните перезагрузку, обязательно подпишите ваш загрузчик, иначе просто ничего не загрузится, ведь SecureBoot активирован и в db прописан ключ, которым будет проверяться подпись любого кода, который будет загружаться UEFI.</note> | ||
- | ==== Подписывание загрузчика ==== | + | === Подписывание загрузчика === |
Т.к. мы активировали SecureBoot, то теперь нам нужно подписать наш загрузчик что бы он мог быть загружен UEFI в этом режиме. | Т.к. мы активировали SecureBoot, то теперь нам нужно подписать наш загрузчик что бы он мог быть загружен UEFI в этом режиме. | ||
В нашем примере мы подпишем код загрузчика GRUB2. | В нашем примере мы подпишем код загрузчика GRUB2. | ||
Строка 310: | Строка 314: | ||
Теперь, можно скрестить пальцы, плюнуть три раза через левое плечо ;-) и попробовать перегрузиться :-o | Теперь, можно скрестить пальцы, плюнуть три раза через левое плечо ;-) и попробовать перегрузиться :-o | ||
- | ==== Возврат в режим Setup ==== | + | === Возврат в режим Setup === |
Переключаться обратно в режим Setup лучше всего из прошивки UEFI, однако теоретически это возможно и внутри OS. Т.к. мы имеем секретный ключ от нашего PK, мы можем попробовать вернуть UEFI из режима User в режим Setup. Для этого потребуется подготовить пустой ключ и записать его в переменную PK: | Переключаться обратно в режим Setup лучше всего из прошивки UEFI, однако теоретически это возможно и внутри OS. Т.к. мы имеем секретный ключ от нашего PK, мы можем попробовать вернуть UEFI из режима User в режим Setup. Для этого потребуется подготовить пустой ключ и записать его в переменную PK: | ||
Строка 442: | Строка 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> "диски", а значит на них можно сослаться при задании команды загрузки для опции загрузки ОС. | ||
Строка 476: | Строка 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-руководства и есть примеры использованию в Интернете, поэтому я не стану останавливаться на деталях использования этих утилит. | ||
Строка 497: | Строка 502: | ||
После этой новости состоялся [[https://github.com/systemd/systemd/issues/2402|наезд]] на разработчиков SystemD (ну на них многие любят наезжать и ругаться, а те собственно сами довольно часто дают повод для вполне обоснованной и справедливой ругани в свой адрес): мол какого лешего, SystemD монтирует эти переменные с возможностью записи!? Давайте типа быстро переделайте на монтирование в режиме только-чтение. На что был дан резонный ответ - доступ на запись нужен утилитам, и разрешена запись только руту, который при желании премонтирует эти переменные в режиме записи. Так что, это не защитит от <del>идиотов</del> <del>дураков</del> "умников", которые экспериментируют с патчем Бармина. | После этой новости состоялся [[https://github.com/systemd/systemd/issues/2402|наезд]] на разработчиков SystemD (ну на них многие любят наезжать и ругаться, а те собственно сами довольно часто дают повод для вполне обоснованной и справедливой ругани в свой адрес): мол какого лешего, SystemD монтирует эти переменные с возможностью записи!? Давайте типа быстро переделайте на монтирование в режиме только-чтение. На что был дан резонный ответ - доступ на запись нужен утилитам, и разрешена запись только руту, который при желании премонтирует эти переменные в режиме записи. Так что, это не защитит от <del>идиотов</del> <del>дураков</del> "умников", которые экспериментируют с патчем Бармина. | ||
+ | |||
+ | Правда позже некоторые контрмеры все-таки были предприняты: теперь все UEFI переменные монтируются со специальным атрибутом, который запрещает запись и удаление этих файлов даже руту. Однако root в состоянии снять эти флаги (сhattr -i <имя файла>). Так что теперь для повторения судьбы арчевода с ноутбуком MCI нужно не только специальный ключ в команде rm -rf задавать, но еще и предварительно снять защиту с перемнных UEFI. | ||
Самое же примечательное в этой ситуации ИМХО в том, что 20 лет назад отпущенная шутка, до сих пор стреляет, да еще с невиданной доселе мощью. 8-) | Самое же примечательное в этой ситуации ИМХО в том, что 20 лет назад отпущенная шутка, до сих пор стреляет, да еще с невиданной доселе мощью. 8-) | ||
+ | <note>Т.е. если раньше патч успешно уничтожал ОС на компьютере, то теперь стало возможным еще и вывести из строя компьютер (при кривой реализации UEFI).</note> | ||
Строка 505: | Строка 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}} | ||