uefi Сравнение версий

Различия

Здесь показаны различия между двумя версиями данной страницы.

Ссылка на это сравнение

Предыдущая версия справа и слева Предыдущая версия
Следующая версия
Предыдущая версия
uefi [2016/11/14 00:03]
[Совместимость]
— (текущий)
Строка 1: Строка 1:
-===== О UEFI ===== 
  
-<​note>​Вообще,​ представленный в статье материл не относятся исключительно к Ubuntu. В статье освящены и вопросы на прямую не зависящие от ОС. 
- 
-Статья сфокусирована на объяснении понятий и принципов,​ а также важных и интересных возможностях UEFI. Более детально сам процесс установки и настройки загрузки Ubuntu в UEFI режиме описан в [[wiki:​установка_дистрибутива_на_компьютер_с_efi|этой статье]] или в [[wiki:​руководство_по_ubuntu_desktop_14_04:​особенности_установки_на_платы_с_uefi|этой]].</​note>​ 
- 
-Практически все современные компьютеры оснащены системной прошивкой позволяющей загрузиться через UEFI. На более старых компьютерах за загрузку отвечал BIOS. В чем разница и как с этим всем жить - давайте разберемся. 
- 
-==== BIOS ==== 
-Старый добрый BIOS отвечает за первичное тестирование ​ ([[https://​ru.wikipedia.org/​wiki/​POST_(%D0%B0%D0%BF%D0%BF%D0%B0%D1%80%D0%B0%D1%82%D0%BD%D0%BE%D0%B5_%D0%BE%D0%B1%D0%B5%D1%81%D0%BF%D0%B5%D1%87%D0%B5%D0%BD%D0%B8%D0%B5)|POST]]),​ инициализацию практически всего аппаратного обеспечения компьютера и за инициализацию загрузки ОС с дискового носителя (хотя сегодня уже не все носители имеют в своей конструкции диск :-) ). 
- 
-Проблемой BIOS принято считать то, что много работы он делает зря (чем затягивает процесс загрузки системы). Практически всю его работу по инициализации и поддержке оборудования компьютера все современные ОС попросту игнорируют и повторно инициализируют и далее работают через свои драйвера. Все, что дает BIOS, было реально востребовано только в ранних версиях DOS... 
- 
-Другой проблемой являются ограничения,​ которые установлены для поддержки BIOS: это 16-ти разрядный реальный режим работы процессора с набором команд i8086, 1Мб адресуемого пространства памяти и периферия (клавиатура,​ видео адаптер,​ контроллер прямого доступа в память) совместимая с IBM AT. На сегодняшний день, требовать от 64-х разрядного многоядерного процессора совместимости с 16-разрядным i8086 - уже немного смешно,​ а требование совместимости по периферии с IBM AT уже даже не смешно,​ а очень грустно. 
- 
-==== (U)EFI ==== 
-Идея отказаться от всего того ненужного,​ что делает BIOS, снять ограничения BIOS и сделать процесс инициализации и загрузки более гибким возникала уже очень давно, и различные попытки сделать это предпринимались,​ но IT-индустрия реально созрела к принятию нового общего стандарта загрузки персональных компьютеров только в начале этого века. В 2005 был создан консорциуму 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) и умеет загружать драйвера для оборудования.\\ 
-После включения компьютера и проведения первичного теста оборудования (на этом этапе разницы с BIOS нет) инициализируются только те подсистемы,​ которые необходимые для загрузки. 
- 
-В некоторых режимах загрузки,​ которые обычно называют Fast-boot (или Fast-Startup) даже клавиатура может оставаться не инициализированной пока не загрузится ОС. Некоторые настройки Fast-boot могут отключать работу со всеми USB устройствами и не будет возможности даже выбрать с чего грузится компьютеру,​ ведь клавиатура не работает до тех пор, пока не загрузится ОС.  
- 
-Причем,​ в отличии от BIOS, все компоненты которого записаны в постоянную(флеш) память,​ UEFI хранит часть своего кода на диске - в специальном разделе ESP((на самом деле ESP раздел может быть и на флеш-памяти и даже на сетевом хранилище,​ но эта экзотика (предусмотренная стандартом) вряд ли будет востребована простыми пользователями)). Это позволяет легко расширять,​ менять и обновлять код поддерживающий различные устройства компьютера без необходимости перепрограммировать постоянное ЗУ компьютера. А кроме драйверов для поддержки устройств на ESP разделе может хранится и поддержка протоколов,​ утилиты и даже собственная EFI-оболочка (shell), из-под которой можно запускать собственные EFI-приложения. Т.е. UEFI по сути - маленькая ОС (или псевдо-ОС). При этом загрузчик операционной системы - становится обычным приложением,​ которое исполняется в окружении,​ предоставляемом псевдо-ОС UEFI. 
- 
-UEFI реализует свой менеджер загрузки,​ он поддерживает мульти-загрузку:​ позволяет выбирать загрузку из нескольких ОС и/или утилит. Загрузчик ОС - это просто efi-приложение,​ которое хранится на ESP разделе. В ESP может храниться много приложений,​ и пункты меню загрузки могут ссылаться каждый на свое приложение (или на одно, но с передачей разных параметров). Кроме того, UEFI поддерживает ассоциацию нажатия клавиш с пунктами загрузки (выбор пункта загрузки осуществляется в зависимости от того какая нажата клавиша в момент загрузки). Т.о. UEFI берет на себя большую часть задач, которые раньше могли решать только загрузчики ОС (типа GRUB). 
- 
-Архитектура UEFI позволяет также загрузить драйвера устройств (необходимые для работы ОС и для процедуры загрузки). Да и само ядро ОС можно загрузить (по крайней мере ядро Linux, собранное с опцией UEFISTUB) непосредственно из UEFI (т.е. устранить загрузчик из процесса загрузки). Такую возможность мы разберем более детально чуть позже. 
- 
-Как и в случае с BIOS, UEFI - это стандарт,​ реализацией которого занимаются разные поставщики решений. Поэтому в реализации UEFI стандарта в прошивках разных поставщиков могут несколько отличаться. Различия в реализации,​ как правило,​ касаются интерфейса утилиты настройки,​ а вот реализация методов работы самого UEFI в процессе загрузки различаться сильно не должна (по крайней мере при строгом следовании стандарту UEFI). Могут встречаться красивые графические утилиты настройки UEFI, иногда даже с поддержкой мыши (например от ASUS) или текстовые,​ с элементами псевдо-графики,​ очень сильно напоминающих интерфейс настройки BIOS (например от AMI). Но значение имеет не способ оформления интерфейса,​ а те настройки,​ которые доступны для изменения через этот интерфейс. 
-==== Совместимость ==== 
-Само собой, современные прошивки умеют эмулировать работу BIOS. Отвечает за совместимость с BIOS модуль CSM (Compatibility Support Module иногда он еще называется Legasy support). Когда CSM включен,​ то при загрузке он пытается найти загрузчик ОС в первом секторе диска (MBR) или в специальном служебном разделе (при GPT разбивке диска). Если код загрузчика найден,​ то CSM считает,​ что установлена ОС требующая поддержки BIOS режима,​ и прежде чем загрузить и запустить код из MBR, CSM проделывает все те же шаги инициализации оборудования,​ что предусмотрены для BIOS. 
- 
-Если вы планируете использовать загрузку в варианте UEFI, то работу этого модуля лучше запретить в системной утилите вашей материнской платы (Firmware setup utility). Кроме того, загрузка в режиме SecureBoot (о ней будет рассказано ниже) явно требует,​ что бы работа модуля CSM была запрещена. 
-<note important>​Собственно использовать стазу оба варианта загрузки (для разных ОС) - не стоит. Лучше для всех ОС установленных на данном компьютере использовать один вариант загрузки:​ через CSM или UEFI.</​note>​ 
-==== ESP раздел ==== 
-Отдельно стоит рассмотреть служебный раздел UEFI. 
-Раздел обязательно должен иметь специальный идентификатор UUID = C12A7328-F81F-11D2-BA4B-00A0C93EC93B (или тип EF если он создан на диске с таблицей разделов в MBR). 
-По стандарту этот раздел должен иметь файловую систему FAT, а если точнее - FAT32 (в принципе стандарт допускает использование других ФС, но на практике это не распространено). 
-Предусмотренная в стандарте структура каталогов довольно проста. 
-  * В корне системного раздела могут располагаться системные утилиты (например тот же шелл-интерпритатор). 
-  * В каталогах EFI\<​Поставщик>​((в UEFI используются обратные косые в качестве разделителей)) должны лежать загрузчики ОС указанного поставщика. 
-  * Если у UEFI нет явного указания какой загрузчик загружать,​ то он загружает файл EFI\BOOT\BOOTx64.EFI (...x32.EFI для 32-х битных платформ). ​ 
-При установке UBUNTU (с загрузкой через UEFI) служебный раздел ESP монтируется в /boot/efi. И на ESP разделе создается каталог EFI\ubuntu в котором размещается загрузчик((Виндовый загрузчик размещается в EFI\Microsoft\Boot\Bootmgfw.efi)) GRUB и/или Shim (о них - чуть позже). 
-<note important>​EFS раздел лучше создавать из установщика. Когда вы делаете его сами через gparted/​parted/​fdisk,​ то есть шанс сделать что-то не так (например выберете FAT16 вместо FAT32) и тогда UEFI не поймет,​ что это EFS раздел и не будет с него загружаться. Доверьте установщику выполнить работу,​ которую он умеет делать хорошо - делайте EFS раздел из установщика.</​note>​ 
-===== MBR и GPT ===== 
-Еще одно "​новшество"​ в индустрии относится к таблице разделов диска. ​ 
- 
-Во времена IBM-PC/AT и BIOS таблица разделов размещалась в первом секторе на диске, т.е. в [[https://​ru.wikipedia.org/​wiki/​%D0%93%D0%BB%D0%B0%D0%B2%D0%BD%D0%B0%D1%8F_%D0%B7%D0%B0%D0%B3%D1%80%D1%83%D0%B7%D0%BE%D1%87%D0%BD%D0%B0%D1%8F_%D0%B7%D0%B0%D0%BF%D0%B8%D1%81%D1%8C|MBR]] (Master Boot Record). В MBR хранится и исполняемый код загрузчика ОС и таблица разделов. Т.к. в 512((это стандартный размер сектора,​ который и по сей день фигурирует как логический,​ хотя практически все современные диски имеют физический размер сектора 2048, 4096 или даже 8192 байта)) байт много не запихнешь,​ то таблица разделов была рассчитана только на 4 раздела. Изначальное ограничение на 4 раздела позже было обойдено через внедрение расширенного раздела - внутри него можно было создать множество логических разделов ((теоретически неограниченное количество,​ т.к. каждый логический раздел содержит указатель на начало следующего)). 
-Более того, на указатели начала и конца раздела было зарезервировано 32 бита, что позволяло адресовать 2 терабайта (что в те времена казалось просто астрономически много :-) ). 
- 
-Однако уже к началу 2010-х на рынке стали появляться диски более 2Тб. Но к этому времени уже набрал популярность стандарт таблицы разделов [[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]] (GUID Partition Table). В GPT установлена новая планка для размера диска: 9,4 ЗБ, т.е 9,4 × 10^21 байт (на сегодня этот размер вновь выглядит астрономически большим... :-) ) 
- 
-К чему я упомянул про таблицы разбиения дисков?​ А к тому, что несмотря на то, что UEFI планировалось использовать только с GPT, а BIOS "​умеет"​((BIOS,​ на самом деле, понятия не имеет, что там и как записано в таблице разделов,​ он просто загружает MBR в память и запускает содержащийся в нем код)) работать только с таблицей разделов в MBR, но в реальной жизни и BIOS (вернее сказать CSM) научили понимать GPT, и для UEFI предусмотрели использование таблицы разделов из MBR. 
- 
-Получившаяся в результате "​солянка"​ (из 4-х допустимых вариантов:​ UEFI + MBR, UEFI + GPT, BIOS/SCM + MBR и BIOS/SCM + GPT) создает некоторую путаницу и недопонимание. Давайте попробуем во всем этом разобраться более детально. 
- 
-===== Что нужно для того что бы ОС грузилась через BIOS? ===== 
-<​note>​Несмотря на то, что загрузка в режиме BIOS уже не современна,​ не модна :-), а главное - технологически устарела,​ но, уверен,​ будет еще много сторонников этого пути, на протяжении долгих лет... Однако я не могу найти ни одного разумного довода использовать этот вариант если и ОС и компьютер поддерживают загрузку через UEFI.</​note>​ 
-В первую очередь,​ для загрузки через BIOS, в утилите настройки вашего компьютера должна быть разрешена работа модуля CSM. Само собой, SecureBoot режим (о нем рассказано чуть ниже) в таком варианте организовать невозможно в принципе. 
- 
-Если разбивка диска - c таблицей разделов в MBR (вариант "​BIOS/​SCM + MBR"), то ничего дополнительно не нужно (это сочетание собственно и есть оригинальная конфигурация для варианта загрузки через BIOS). 
- 
-А вот если у вас диск размечен через GPT (вариант "​BIOS/​SCM + GPT"), то возникают некоторые сложности. \\ 
-В первую очередь:​ не совсем ясно - куда разместить код, который ранее размещался в MBR. Да, в GPT первый блок размером в 512 байт зарезервирован и в нем даже есть защитная версия таблицы разделов (в формате принятом для MBR). В защитной таблице разделов записан единственный раздел размером на все адресуемое пространство диска((или на первые 2ТБ, если диск имеет объем более чем 2ТБ)) и с типом EE. Само собой, с единственной фейковой записью в таблице разделов никакой код в MBR не сможет корректно отработать процесс загрузки((Само собой, в таблицу разделов можно добавить еще 3 записи,​ это хоть и делает возможной загрузку кодом из MBR, но создает ситуацию,​ при которой на диске одновременно действуют две таблицы разделов разного формата. Такие гибридные системы удается реализовать энтузиастам,​ но массовому пользователю использовать такие схемы не рекомендуется в виду сложности настройки и поддержания работоспособности такой системы)).\\ 
-Еще одно проблемное место возникает когда загрузчик использует для размещения своего кода сектора на первом треке диска за MBR (к примеру так поступает GRUB). В GPT на этом месте уже идут служебные записи (заголовок таблицы разделов и сами записи о разделах).\\ 
-Для решения обоих этих проблем предусмотрен специальный бинарный (он не форматируется ни в какую ФС) раздел BIOS-Boot (Тип = EF02 или UUID = 21686148-6449-6E6F-744E-656564454649). Установщик ОС может прописать на этот раздел весь тот код, который ранее размещался в MBR и на незанятом пространстве за MBR. Этот раздел должен иметь установленный флаг boot. Размер этого раздела может быть совсем маленьким,​ ведь MBR - это всего 512 байт, а размер неиспользуемого пространства за MBR, составляет всего 31Кb. Однако,​ некоторые современные загрузчики требуют раздел BIOS-Boot размером в 10-30Мb.\\ 
-В процессе загрузки CSM модуль (эмулирующий работу BIOS) отвечает за то, что находит в GPT раздел BIOS-Boot, загружает первые 512 байт с этого раздела,​ и передает управление загруженному коду. За дальнейший процесс загрузки отвечает этот код, а CSM берет на себя задачу эмулировать обращение к секторам диска за MBR (вместо этих секторов производится подстановка секторов из раздела BIOS-Boot). 
- 
-<​note>​Пожалуй вот на этом и закончим обсуждать CSM и BIOS, все дальнейшее будет относится только к UEFI.</​note>​ 
-===== Что нужно для установки ОС, что бы она грузилась через UEFI? ===== 
-На самом деле все не так сложно как кажется. Как уже было сказано UEFI требует специального раздела ESP (с файловой системой FAT32 и флагами boot и esp). И, несмотря на то, что для этого раздела был предусмотрен специальный длинный идентификатор (UUID = C12A7328-F81F-11D2-BA4B-00A0C93EC93B) для GPT, который в таблицу разделов MBR ну никак не запихнешь,​ этому разделу дали еще и короткий идентификатор (EF), который можно "​впихнуть"​ в таблицу разделов в MBR. Т.е. ESP раздел можно создать и на диске с GPT и на диске с таблицей разделов в MBR (однако такой вариант поддерживает не любая ОС). 
- 
-Т.о. при установке системы,​ помимо создания нужных для работы ОС разделов,​ нужно создать специальный раздел ESP: 
- 
-- для варианта «UEFI + MBR» : c типом EF  
- 
-- для варианта «UEFI + GPT» : c типом EF00 и UUID = C12A7328-F81F-11D2-BA4B-00A0C93EC93B 
- 
-Этот раздел должен быть отформатирован в FAT32 и иметь установленные флаги boot и esp. Размер раздела можно выбрать небольшим 200-300Мб (занято там будет, скорее всего, гораздо меньше,​ но делать его совсем маленьким,​ при современных объемах дисков - просто бессмысленно). 
- 
-Если ESP раздел создается из установщика Ubuntu, то нужный формат,​ точку монтирования и необходимые флаги установщик сделает сам: нужно только выбрать тип раздела "EFI Boot" и задать его размер. 
- 
-Если на компьютере уже стоит ОС загружающаяся через UEFI, то ESP раздел уже должен быть на диске и новый ESP создавать не нужно. В установщике Ubuntu надо только убедиться,​ что этот раздел используется как "EFI Boot". Более того, если создать несколько разделов ESP (на одном диске),​ то некоторые прошивки UEFI могут "​окриветь"​ из-за такого неожиданного разнообразия. Общее правило - на диске должен быть только один раздел ESP. На разных устройствах ESP разделов может быть несколько - это вполне штатная ситуация для UEFI. 
- 
-<note important>​Ядро Linux загруженное не через UEFI не обеспечивает доступа к переменным UEFI, а это не позволяет изменять настройки загрузки UEFI. Поэтому,​ поставить новый Linux (что бы он загружался через UEFI) можно только предварительно загрузившись с установочного носителя через UEFI.</​note>​ 
-<note important>​Некоторые дистрибутивы не умеют загружаться через UEFI, если у вас таблица разделов в MBR.</​note>​ 
-Для загрузки через UEFI модуль CSM не нужен и если все установленные на компьютере ОС грузятся через UEFI, то CSM лучше отключить. А вот если вы организуете загрузку в режиме SecureBoot, то CSM модуль отключить просто необходимо:​ без этого, обычно,​ просто не включить режим SecureBoot или включение SecureBoot автоматически запрещает работу CSM. 
-===== Secure Boot ===== 
-Особого упоминания требует такая особенность UEFI как Secure Boot. 
- 
-Как уже было сказано EFI раздел (ESP) находится на диске, к которому может быть организован доступ во время работы ОС. Это означает не только легкость в изменении загрузки и инициализации оборудования системы,​ но и то, что туда можно подсунуть заведомо зловредный код, который (О!!! УЖАС!!!:​-o) будет загружен еще ДО!! загрузки ОС. На самом деле, перепрограммировать микросхемы BIOS или подменить код в MBR из запущенной ОС тоже можно было, но на это практически никто раньше не обращал внимания :-). 
- 
-Закрыть эту "​ужасающую дыру"​ в безопасности и призван Secure Boot. Вот как он работает:​ 
- 
-При программировании системной памяти UEFI загрузчика (firmware), производители,​ вместе с кодом, записывают и сертификаты (содержащие ключи),​ и при загрузке в режиме Secure Boot UEFI проверяет по этим ключам подписи у любого исполняемого кода, который он загружает из ESP раздела (подписи добавляются к коду). Если верификация не прошла - такому коду отказывают в запуске. 
- 
-<​note>​Большая шумиха поднялась когда Microsoft заявили,​ что производители оборудования,​ желающие получить сертификат совместимости с Windows 8, обязаны исключить возможность загрузки с отключенным режимом Secure Boot. Дело в том, что это бы не позволило загрузить ни одну ОС, которая была бы не подписана колючем Microsoft. 
- 
-Однако,​ довольно быстро шумиха улеглась. Во-первых Secure Boot практически все производители компьютеров разрешают отключать (Microsoft позже насколько переформулировал свои требования:​ от оборудования сертифицированного под Windows 8 не требуется запрещать загрузку без Secure Boot, зато требуется сообщить загрузчику Windows 8, что загрузка была не в SecureBoot режиме,​ и уже самой Windows решать - грузится ей дальше или нет). А во-вторых,​ в рамках консорциума UEFI были предусмотрены интерфейсы для управления ключами. "​Подсуетились"​ и Canonical, и RedHat вместе с фондом FSF (Free Software Foundation). Как результат всех этих мероприятий и событий - и GRUB, и другие загрузчики обзавелись методами загрузки в режиме Secure Boot, а кроме того, стали доступны утилиты по управлению ключами UEFI. Вы даже можете свой собственный код подписать своим собственным ключом,​ загрузить ключ в UEFI (утилитами из пакета efitools) и это позволит загружать ваш собственный код в Secure Boot режиме. 
- 
-Чуть хуже дело обстоит с планшетами и телефонами с предустановленной Windows - в прошивках этих устройств SecureBoot может быть не отключаем,​ а иногда нет и управления ключами. ​ 
-</​note>​ 
- 
-Все дистрибутивы Ubuntu поддерживающие загрузку через UEFI уже имеют в своем составе все необходимое для загрузки в Secure Boot режиме практически на любом компьютере. Но, если загрузка с установочной флешки или диска не идет, то Secure Boot следует отключить (конечно же Secure Boot - не единственная причина по которой может не происходить загрузка с установочной флешки или диска). 
-<​note>​В Ubuntu раздел ESP монитруется (при стандартной установке) в каталог /boot/efi/. Но правами доступа туда обладает только root (остальные пользователи даже прочитать из этого каталога ничего не могут). Т.е. даже без Secure Boot защита от атак через доступ в ESP раздел предусмотрена на том же уровне,​ на котором защищена и вся система:​ если рута взломали - то уже в принципе ничего не помешает злоумышленнику сделать с системой все, что он пожелает. 
-</​note>​ 
- 
-<note warning>​Обратите внимание:​ режим SecureBoot включается для всего компьютера,​ а это означает,​ что правильно подписанными должны быть все загрузчики (всех установленных ОС), утилиты и драйвера,​ которые загружаются с ESP раздела.</​note>​ 
- 
-===== Ключи системы Secure Boot ===== 
-На самом деле в энергонезависимой памяти компьютера (NVRAM) рассчитанного на работу с UEFI предусмотрено место не на один сертификат,​ более того, сертификаты хранятся в специально организованной,​ иерархической системе. Давайте рассмотри этот вопрос более детально,​ но начнем с того, что определим - что такое сами ключи, о которых мы тут говорим. 
- 
-**Ключи** 
- 
-Что же представляют собой эти ключи? 
-На самом деле хранятся все ключи UEFI в сертификате - бинарном файле контейнере специального формата (специальное расширение стандарта [[https://​ru.wikipedia.org/​wiki/​X.509|x.509]]). ​ 
-Внутри сертификата могут содержаться открытый ключ, информация о владельце ключа, удостоверяющий ключ подписи и иная информация. 
-Сами используемые ключи - это пары ключей (открытый/​публичный и закрытый/​секретный) сформированные алгоритмом [[https://​ru.wikipedia.org/​wiki/​RSA|RSA]]. UEFI стандарт рекомендует использовать ключи длинной 2048 bit. 
- 
-**Набор ключей системы SecureBoot** 
- 
-UEFI стандарт предусматривает следующие ключи (или списки ключей):​ 
-  * **PK** (Platform Key) - Это основной (единственный) ключ системы. Часто это ключ производителя оборудования. 
-  * **KEK** (Key Exchange Keys) - Ключ используемый для обмены ключами. Этих ключей может быть несколько. 
-  * **db** (база разрешенных ключей) - А вот в этом списке и хранятся те самые ключи, которые используются для проверки подписи загружаемых UEFI программ. ​ 
-  * **dbx** (база отозванных ключей) - Здесь хранятся скомпрометированные ключи. Программный код подписанный такими ключами не будет загружаться и исполняться. 
-  * **dbt** (база временных меток) - тут хранятся ключи с отметкой времени (([[https://​www.ietf.org/​rfc/​rfc3161.txt|RFC3161]]))) (оставим пока детальное рассмотрение вопроса использования этих ключей за рамками статьи). 
-  * **dbr** (база ключей для восстановления) - тут хранятся ключи восстановления системы (оставим пока детальное рассмотрение вопроса использования этих ключей за рамками статьи). 
- 
-<​note>​В зависимости от реализации часть ключей может отсутствовать (или даже все, если система вовсе не поддерживает SecureBoot). В самых старых реализациях (поддерживающих SecureBoot) набор ключей мог быть: PK и db. В более свежих могут отсутствовать dbr и/или dbt. 
- 
-Кроме того в NVRAM UEFI могут быть созданы кастомные списки ключей. Примером такого списка служит список ключей MOK (Mashine Owner Keys). MOK ключи используются не самим UEFI, а загрузчиком Shim. Shim (подписанный ключем из db) загружается как обычное UEFI приложение и сам проверяет подпись загружаемого им кода по ключам из MOK. 
-</​note>​ 
- 
-<​note>​Если вам неохота/​лень разбираться в режимах работы UEFI и ключей описанных далее, то можете условно считать,​ что PK ключ должен быть само-подписанным,​ KEK ключ - должен быть подписан ключем PK, а db (dbx|dbt|dbr) ключ должен быть подписан ключем KEK или PK. Если вас устраивает такая упрощенная модель (на самом деле там все несколько сложнее,​ что и описано далее),​ то вы можете смело пропустить остаток этого раздела и перейти сразу к разделу **Собственные ключи**</​note>​ 
- 
-**Состояния системы SecureBoot** 
- 
-Работа с ключем PK сильно зависит от состояния в котором находится UEFI. В спецификации UEFI v2.5 предусмотрено 4 состояния,​ на два из них наиболее важны, а еще два - служебные (они могут быть вовсе не реализованы в некоторых прошивках UEFI). Состояния определяются значениями глобальных переменных UEFI (хранящимися в NVRAM). При этом, в разных состояниях меняется не только значение переменных,​ но и возможность записать в эти переменные новое значение. Далее будет использоваться следующая нотация:​ <​Переменная>​=<​значение>/​[RO|RW],​ где признаки RO и RW говорят о доступности переменной для изменения (RO, от ReadOnly - только чтение;​ RW, от ReadWrite - чтение и запись). 
-  * **Setup** - Режим настройки системы (SetupMode = 1/RO): PK - не определен,​ SecureBoot - не разрешен (SecureBoot = 0/RO), переход в состояние Audit разрешен (AuditMode == 0/RW), а переход в состояние Deployed запрещено (DeployedMode = 0/RO). \\ В этом режиме можно задать PK: он должен иметь удостоверяющую подпись своим собственным секретным ключем (т.е. он должен быть само-подписанным). При задании PK система сразу переходит состояние User. \\ Можно также перейти в состояние Audit, присвоив переменной AuditMode значение 1.  
-  * **User** - Рабочий режим (SetupMode = 0/RO): в этом режиме можно включить или выключить режим SecureBoot (SecureBoot=0/​RW) или((Зависит от реализации,​ т.к. в стандарте это не оговорено)) он включается автоматом,​ при переходе из состояния Setup (SecureBoot=1/​RW),​ а может включаться и фиксироваться (SecureBoot=1/​RO). \\ В этом режиме тоже можно поменять PK, но новый PK должен иметь удостоверяющую подпись секретным ключем текущего PK. \\ Из этого режима можно перейти в Audit (AuditMode = 0/RW) или в Deployed (DeployedMode == 0/RW). Так же можно удалить или очистить PK (реализация зависит от платформы) с автоматическим переходом в состояние Setup. 
-  * **Audit** - служебное состояние для проведения аудита системы - в этом режиме возможна загрузка любых модулей без проверки подписи,​ но о каждой загрузке создается запись в специальной таблице. При присвоении переменной AuditMode значения 1 (возможно в User и Setup) сразу происходят несколько действий:​ система переходит в состояние аналогичное состоянию Setup (SetupMode = 1/RO), отключается SecureBoot (SecureBoot = 0), текущий PK сбрасывается (очищается),​ DeployedMode = 0/RO. \\ Фактически это сброс системы SecureBoot в состояние Setup (что разрешает записать само-подписанный PK). Однако выход из этого режима иной чем из состояния Setup: При установке нового **PK** - состояние меняется на Deployed (AuditMode = 0/RO, DeployedMode = 1/RO, SetupMode = 0/RO). При этом в состоянии Deployed будет отключен SecureBoot. 
-  * **Deployed** - служебное состояние в котором запрещена любая работа с ключами,​ состояние SecureBoot тоже нельзя изменить (если включено - не отключить и наоборот). Как раз в этот режим переведены производителями UEFI на виндо-планшетах и виндо-смартфонах. Перевести в этот режим можно: из состояния User, присвоив глобальной переменной UEFI "​DeployedMode"​ значение 1 или из состояния Audit, задав PK. Как вы правильно понимаете после этого и саму переменную "​DeployedMode"​ уже будет не изменить. \\ Выход из этого режима возможен в User или Setup, а вот механизм выхода - зависит от реализации UEFI (Platform specific DeployedMode clear - как написано в спецификации). Т.е. либо какие-то шаманские действия (возможно и недокументированные) либо вовсе - никак (по крайней мере без аппаратного обнуления NVRAM). 
- 
-KEK ключ может быть добавлен в состояниях Setup (без подписи или само-подписанный) и User (обязательно подписанный секретным ключем от PK). 
- 
-С ключами в db* (db, dbx, dbt, dbr) - все значительно проще и одновременно сложнее:​ Т.к. существует огромное количество операционных систем и их различных версий,​ а также загрузчиков этих ОС, драйверов и утилит от разных поставщиков,​ то поставить (от производителя) систему сразу со всеми нужными ключами - просто нереально. То же касается и ключей,​ которые были скомпрометированы и ключей восстановления. Поэтому предусмотрен режим добавления этих ключей. При этом если система находится в состоянии Setup, то ключи в db* можно добавлять без подписей или само-подписанные,​ а если в User, то добавляемые ключи должны быть подписаны приватной ключем от одного из KEK ключей или от PK. 
- 
-Причем в ключи в db (dbt) могут добавляться и автоматически (если это предусмотрено конкретной реализацией UEFI): когда подпись загружаемого модуля не может быть проверена,​ то могут быть предусмотрены механизмы (поиск в массиве на диске или интерактивное подтверждение от авторизованного пользователя),​ которые разрешат добавить публичный ключ от подписи (подпись содержит публичный ключ для своей проверки) в db (или dbt). 
-===== Собственные ключи =====  
-Так как все ключи/​сертификаты UEFI (PK, KEK, db) построены на основе открытых стандартов,​ то и весь набор этих ключей можно сформировать самостоятельно. Давайте рассмотрим как это можно сделать. 
- 
-<note important>​Прежде чем вы приступите к манипуляциям с ключами,​ настоятельно рекомендуется убедится в том, что ваша прошивка UEFI позволяет отключить SecureBoot из утилиты настройки или удалить/​обнулить PK. Если этой возможности прошивка не предоставляет,​ то подумайте десять раз прежде чем что-либо делать с ключами - ваши шансы трансформировать ваш компьютер/​ноутбук в кирпич крайне высоки!</​note>​ 
- 
-Для работы нам потребуются утилита openssh (практически во всех дистрибутивах Linux эта утилита уже установлена) и утилиты из пакета efitools (доступна в репозиориях ubuntu((для установки выполните:​ sudo apt-get install efitools))). 
-==== Создание ключей ===== 
-Для начала создадим наш тестовый ключ и само-подписанный сертификат:​ 
- 
-<​code>​$ openssl genrsa -out test-key.rsa 2048 
-$ openssl req -new -x509 -sha256 -subj '/​CN=test-key'​ -key test-key.rsa -out test-cert.pem 
-$ openssl x509 -in test-cert.pem -inform PEM -out test-cert.der -outform DER  
-</​code>​ 
- 
-<​note>​Как показали мои эксперименты с UEFI прошивкой от AMI - срок действия сертификата в db не имеет значения для загрузки в режиме SecureBoot (подписанный моим собственным ключем UEFI-Shell продолжал загружаться в режиме SecureBoot и после окончания срока действия сертификата). Однако я не берусь гарантировать,​ что это не может быть важно для какой-либо другой реализации UEFI. Если это окажется важно, то нужно задать разумное время действия сертификата во второй команде через опцию -days <n> : где <n> - число дней в течении которых сертификат действует (по умолчанию задается - один месяц, чего самом собой - маловато...).</​note>​ 
- 
-Для дальнейших действий нам потребуется GUID для идентификации нашего ключа. Его очень просто сформировать через утилиту uuidgen, а для удобства новый GUID мы запишем в переменную. 
- 
-<​code>​$ guid=$(uuidgen) 
-$ echo $guid 
-c752155d-093f-4441-87c3-20e2352205ac</​code>​ 
- 
-==== Создание UEFI ключей ===== 
-Для того что бы установить наш ключ в базу ключей UEFI, нам потребуется специальны контейнер EFI_SIGNATURE_LIST,​ в котором будет задана переменная EFI_VARIABLE_AUTHENTICATION_2. Для упрощения,​ ключи в контейнере будут само-подписанными. 
- 
-Сначала мы создаем контейнер EFI_SIGNATURE_LIST содержащий сертификат:​ 
- 
-<​code>​$ sbsiglist --owner $guid --type x509 --output test-cert.der.siglist test-cert.der</​code>​ 
- 
-Далее создадим подписанные ключи для последующей загрузки в энергонезависимую память UEFI. Наши файлы будут содержать сертификат с префиксом в виде EFI_VARIABLE_AUTHENTICATION_2 описателя. Описатель будет подписывать ключ, и содержать название переменной и другие атрибуты. Т.к. в файл будет включено название переменной (PK, KEK and db), нам придется создать отдельный контейнер для каждой переменной. 
- 
-<​code>​$ for n in PK KEK db 
-> do 
->   ​sbvarsign --key test-key.rsa --cert test-cert.pem \ 
->     ​--output test-cert.der.siglist.$n.signed \ 
->     $n test-cert.der.siglist 
-> done</​code>​ 
- 
-<​note>​Здесь мы несколько упрощаем стандарт работы ключей UEFI: у нас не будет выстроена цепочка удостоверяющих подписей различающихся ключей:​ PK -> KEK -> db. Все три ключа у нас - само-подписанные и в PK, KEK и в db будет записан одинаковый ключ (чисто формально они удостоверяют подписи друг друга по цепочке). Ключ который мы будем записывать - тот самый rsa ключ, который мы сформировали самой первой командой. Можно, конечно,​ сформировать различающиеся ключи для PK, KEK и db, но не совсем понятно - зачем нужно такое усложнение в нашем случае. 
- 
-Кроме того, все известные сертификаты от разработчиков 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 будет их искать. 
- 
-<​code>​$ sudo mkdir -p /​etc/​secureboot/​keys/​{PK,​KEK,​db,​dbx} 
-$ sudo cp *.PK.signed /​etc/​secureboot/​keys/​PK/​ 
-$ sudo cp *.KEK.signed /​etc/​secureboot/​keys/​KEK/​ 
-$ sudo cp *.db.signed /​etc/​secureboot/​keys/​db/</​code>​ 
- 
-На самом деле вы можете создать хранилище где угодно и указать утилите sbkeysync где оно находится в значении ключа --keystore. 
- 
-==== Загрузка ключей ==== 
-=== Через утилиту прошивки ===  
-Загрузка ключей в UEFI может быть выполнена из утилиты настройки вашей материнской платы. Там нужно будет найти раздел (обычно Security) где задаются параметры SecureBoot. Возможно потребуется явно разрешить работу с ключами - выбрать режим управления ключами custom или как либо еще. 
-Попав в окно утилиты по управлению ключами,​ первым делом сохраните (на всякий случай) фабричные ключи((Если ваша прошивка предоставляет опцию установки/​восстановления фабричных ключей,​ то свою резервную копию фабричных ключей вам создавать не обязательно.)). После этого удалите все фабричные ключи, и по одному добавляйте ключи из вашего хранилища ключей (скорее всего, его придется перенести на ESP раздел,​ т.к. только этот раздел доступен для UEFI).\\ 
- 
-PK ключ желательно записывать последним (почему?​ - детально описано в финальной части раздела [[http://​help.ubuntu.ru/​uefi?&#​ключи_системы_secure_boot|"​Ключи системы SecureBoot"​]]). 
- 
-Следует также отметить,​ что формат,​ в котором прошивка умеет загружать ключи может разниться в разных прошивках UEFI. Например прошивка AMI из недавно купленного мини-PC может взять сертификат и из подготовленного контейнера,​ и непосредственно из файла .pem. Т.о. вся эта возня со специальными контейнерами,​ в этом случае,​ вовсе не нужна: один и тот же само-подписанный сертификат можно загрузить и в PK, и в KEK, и в db.    ​ 
-=== Используя sbkeysync ===  
-Если UEFI находится в Setup режиме,​ то ключи можно загрузить и из ОС, используя утилиту sbkeysync. Но для начала воспользуйтесь опцией --dry-run, что бы убедится,​ что у вас все верно настроено и готово к этому важному процессу:​ 
- 
-<​code>​$ sbkeysync --verbose --pk --dry-run 
-Filesystem keystore: 
-  /​etc/​secureboot/​keys/​db/​test-cert.der.siglist.db.signed [2116 bytes] 
-  /​etc/​secureboot/​keys/​KEK/​test-cert.der.siglist.KEK.signed [2116 bytes] 
-  /​etc/​secureboot/​keys/​PK/​test-cert.der.siglist.PK.signed [2116 bytes] 
-firmware keys: 
-  PK: 
-  KEK: 
-  db: 
-  dbx: 
-filesystem keys: 
-  PK: 
-    /​CN=test-key 
-     from /​etc/​secureboot/​keys/​PK/​test-cert.der.siglist.PK.signed 
-  KEK: 
-    /​CN=test-key 
-     from /​etc/​secureboot/​keys/​KEK/​test-cert.der.siglist.KEK.signed 
-  db: 
-    /​CN=test-key 
-     from /​etc/​secureboot/​keys/​db/​test-cert.der.siglist.db.signed 
-  dbx: 
-New keys in filesystem: 
- /​etc/​secureboot/​keys/​db/​test-cert.der.siglist.db.signed 
- /​etc/​secureboot/​keys/​KEK/​test-cert.der.siglist.KEK.signed 
- /​etc/​secureboot/​keys/​PK/​test-cert.der.siglist.PK.signed</​code>​ 
- 
-Вывод покажет списки ключей найденных в базе данных UEFI, ключей найденных в хранилище ключей и список синхронизации (какой ключ куда будет загружен). 
- 
-Если все выглядит правильно,​ удалите --dry-run параметр из команды для фактического обновления ключей в UEFI базе данных. ​ 
-<note important>​Будьте предельно осторожны выполняя загрузку ключей,​ т.к. как только PK будет записан прошивка UEFI перейдет в режим User, а в некоторых прошивках это еще автоматом включит SecureBoot режим. Вы должны быть уверены,​ что прошивка UEFI позволит вам вернутся в Setup режим и/или удалить PK.</​note>​ 
-<​note>​Некоторые прошивки требуют перезагрузки для применения этих изменений в переменных UEFI. Прежде чем вы выполните перезагрузку,​ обязательно подпишите ваш загрузчик,​ иначе просто ничего не загрузится,​ ведь SecureBoot активирован и в db прописан ключ, которым будет проверяться подпись любого кода, который будет загружаться UEFI.</​note>​ 
-==== Подписывание загрузчика ==== 
-Т.к. мы активировали SecureBoot, то теперь нам нужно подписать наш загрузчик что бы он мог быть загружен UEFI в этом режиме. ​ 
-В нашем примере мы подпишем код загрузчика GRUB2. 
-<note important>​ Это не рекомендуется в работающих системах,​ т.к. код этого загрузчика довольно регулярно обновляется,​ подписывать его придется каждый раз после обновления! 
-</​note>​ 
-<​code>​$ sbsign --key test-key.rsa --cert test-cert.pem \ 
-        --output grubx64.efi /​boot/​efi/​EFI/​ubuntu/​grubx64.efi 
-$ sudo cp /​boot/​efi/​EFI/​ubuntu/​grubx64.efi{,​.bak} 
-$ sudo cp grubx64.efi /​boot/​efi/​EFI/​ubuntu/</​code>​ 
-Теперь,​ можно скрестить пальцы,​ плюнуть три раза через левое плечо ;-) и попробовать перегрузиться :-o 
- 
-==== Возврат в режим Setup ==== 
-Переключаться обратно в режим Setup лучше всего из прошивки UEFI, однако теоретически это возможно и внутри OS. Т.к. мы имеем секретный ключ от нашего PK, мы можем попробовать вернуть UEFI из режима User в режим Setup. Для этого потребуется подготовить пустой ключ и записать его в переменную PK: 
- 
-<​code>​$ : > empty 
-$ sbvarsign --key test-key.rsa --cert test-cert.pem \ 
-        --attrs NON_VOLATILE,​BOOTSERVICE_ACCESS,​RUNTIME_ACCESS \ 
-        --include-attrs --output empty.PK.signed PK empty 
-$ sudo dd bs=4k if=empty.PK.signed \ 
-        of=/​sys/​firmware/​efi/​vars/​PK-8be4df61-93ca-11d2-aa0d-00e098032b8c</​code>​ 
- 
-Хотя лучше убедиться,​ что вернуть UEFI в режим Setup можно из самой прошивки (утилиты настройки) перед тем как прописывать PK. 
-===== Как Ubuntu загружается в режиме Secure Boot ===== 
-Как уже было сказано выше, сертификаты с ключами для загрузки в режиме Secure Boot записываются производителем оборудования ([[https://​wiki.ubuntu.com/​SecurityTeam/​SecureBoot#​Introduction|довольно подробно о ключах UEFI (англ.)]]). И, как правило,​ набор сертификатов состоит из: сертификата производителя,​ KEK и db ключей от Microsoft (конечно же). Крайне редко, но все же попадаются такие машины,​ у которых в db есть и ключ от Canonical и/или RedHad. Как же на машине c ключами только от Microsoft загрузить Ubuntu в режиме SecureBoot?​\\ 
-Решение было найдено:​ Microsoft согласился (не без активности со стороны Canonical) подписать своим ключом простенький загрузчик от Red Hat - shim (есть еще мини-загрузчик - PRELoader, о его подписании ключом Microsoft похлопотал фонд FSF).  ​ 
-Shim, в свою очередь,​ содержит (в MOK) UEFI сертификат от Canonical и проверяет подпись GRUB2 (версия которого,​ распространяемая через репозитории Ubuntu, подписана ключем Canonical). А GRUB2 проверяет подпись ядра (которое тоже подписано Canonical). 
- 
-Введение дополнительного звена в виде shim продиктовано тем, что GRUB довольно часто обновляется и каждый раз после обновления его надо подписывать. Само собой, его гораздо проще подписать собственным ключом Canonical нежели каждый раз снова договариваться с Microsoft. 
- 
-Если вы не хотите оставлять сертификаты Microsoft и производителя на своей машине((не станем называть это паранойей... кто там знает, что могло быть подписано парными ключами от тех, что лежат в этих сертификатах...)),​ то из утилиты настройки вашей материнской платы или с помощью утилит efitools можно стереть сертификаты прописанные производителем,​ и записать в UEFI (db) ключ от Canonical, тогда уже Grub (так же как и само ядро Linux) сможет загружаться в режиме Secure Boot, и shim (со своим MOK) - не нужен. 
- 
-Если вам не хочется даже сертификат от Canonical оставлять в своем компьютере((ну... и это тоже - не будем считать паранойей...)),​ то вы можете создать свои собственные ключи и сертификаты (как описано выше), подписать grub или само ядро Linux (утилитой sbsign из пакета sbsigntool) и записать ключи в базу данных ключей EFI (утилитами efitools).  ​ 
-Подробно этот процесс описан выше и [[http://​jk.ozlabs.org/​docs/​sbkeysync-maintaing-uefi-key-databases/​|тут]] (англ.). 
- 
-<note warning>​ВНИМАНИЕ,​ если ваш компьютер не позволяет отключить Secure Boot режим, то все манипуляции с ключами и подписями нужно проделывать с предельной осторожностью,​ т.к. любая ошибка может привести к тому, что ваш компьютер превратится в "​кирпич"​!!!\\ \\ 
-Проверяйте все ваши настройки,​ проверяйте,​ что в UEFI записаны именно те ключи, что вы хотели и не забудьте проверить правильность подписей.\\ \\ 
-Хорошая идея: проделать все сначала на [[https://​wiki.ubuntu.com/​SecurityTeam/​SecureBoot#​VM_installation_and_preparation|виртуальной машине]].</​note>​ 
-<note warning>​ВНИМАНИЕ,​ если вы организовали загрузку GRUB (или другого загрузчика что вы используете) на основе только своего собственного ключа, то внимательно следите за обновлениями:​ при обновлении GRUB вам необходимо подписать новую версию GRUB своим ключом,​ иначе он не загрузится в Secure Boot режиме.</​note>​ 
- 
-===== Другие интересные возможности UEFI ===== 
- 
-==== UEFI Shell ==== 
-UEFI shell часто уже установлен в разделе ESP или прямо в прошивке UEFI. Некоторые UEFI прошивки умеют загружать командный интерпретатор UEFI прямо из консоли настройки UEFI (BIOS).\\ 
- 
-Если вы ставили Ubuntu на чистый диск, а в прошивке нет встроенного UEFI shell, то его можно доставить руками. Сам бинарный файл легко находится через любой поисковик. Вам нужно будет только скопировать его в корень ESP раздела с именем shellx64.efi (для 32-х битных платформ:​ shellx32.efi). Само собой копировать надо через sudo (т.е. с правами root).\\ 
-<note important>​В режиме загрузки SecureBoot для загрузки UEFI Shell потребуется:​ 
-  * Либо отключать для его загрузки режим SecureBoot 
-  * Либо подписать бинарный код UEFI Shell парным секретным ключем от одного из ключей записанных в переменной db базы данных ключей UEFI. 
-</​note>​ 
-Если из настроек UEFI нет возможности запустить UEFI shell, то можно его прописать как вариант загрузки (как вы помните UEFI поддерживает мульти-загрузку). Для этого воспользуемся утилитой efibootmg: 
- 
-<​code>#​ efibootmgr -c -l \\shellx64.efi -L UEFIshell</​code>​ 
- 
-После этой команды у вас появится новый пункт меню загрузки UEFI, и это новый пункт станет первым по приоритету. Если такой приоритет загрузки вас не устраивает,​ то поменяйте его с помощью опции "​-o"​ утилиты efibootmgr. 
- 
-Справочник по командам UEFI shell встроенный - команда help. Если вы хотите останавливать вывод постранично (некий аналог more) то используйте в командах ключ **-b**. Кроме того поддерживается история вывода на 3 страницы которые можно просмотреть используя кнопки PageUp и PageDown. 
- 
-Команда map покажет известные UEFI диски и разделы. Обычно диск fs0: - это и есть раздел ESP. Для того, что бы просмотреть содержимое каталогов ESP раздела (ls) выполните переход на ESP раздел - введите в строке приглашения **fs0:** - это очень похоже на dos команды типа а: с: (если кто еще помнит такое). 
- 
-Разделитель в путях тоже в стиле DOS - обратный слеш (\). 
- 
-EFI shell имеет довольно обширный набор команд,​ все их тут описывать смысла нет - если не достаточно встроенной подсказки,​ то есть ​ краткие руководства в Internet. Наиболее полное писание UEFI Shell и его команд я нашел только в [[http://​www.uefi.org/​sites/​default/​files/​resources/​UEFI_Shell_Spec_2_0.pdf|спецификации UEFI Shell 2.0 на сайте UEFI.org]]. ​ 
-==== Загрузка ядра из UEFI ==== 
-Если вы взгляните в файловом менеджере на ядро (/​boot/​vmlinuz*) то вы можете немало удивиться,​ заметив что тип будет указан как "​DOS/​Windows executable"​ - не удивляйтесь. Все последние ядра в Ubuntu собираются с опцией UEFISTUB (поддержка загрузки в режиме UEFI). А это добавляет заголовок аналогичный ДОСовскому .exe (именно так должны собираться все UEFI приложения). Т.е. само ядро можно загрузить как UEFI приложение. Для этого нужно разобраться с двумя основными вопросами:​ 
- 
-1. Как правильно передать ядру параметры?​ Т.е. указать на корневую файловую систему,​ образ initrd, и указать опции загрузки ядра.\\ 
-2. Как обеспечить UEFI доступ к самому ядру (и initrd)? 
- 
-По первому пункту все достаточно просто:​ параметры,​ которые нужно передать ядру для загрузки можно подсмотреть в /​boot/​grub/​grub.cfg,​ в команде загрузки linux (там стандартно передаются указание на корневой раздел и опции типа "​ro",​ "​quiet"​ и "​splash"​). Дополнительно ядру надо будет сообщить,​ где найти initrd (в ядрах версии 3.3 и выше это можно сделать через параметр intrd). В итоге, та команда,​ которую должен выполнить UEFI будет выглядеть примерно так: 
- 
-<​code>​vmlinuz.efi root=UUID=0160863a-1468-422b-8bbb-f80e98e3600d ro quiet splash initrd=initrd</​code>​ 
-В этом примере ядро и initrd лежат непосредственно в корне ESP раздела. Ядро переименовано в "​vmlinuz.efi",​ а соответствующий ему образ рамдиска начальной инициализации ядра в "​initrd"​. В команде указан UUID (моего корня, вам нужно прописать свой UUID) как путь к корневому разделу,​ но можно написать и что-то типа root=/​dev/​sda2 (UUID все же - лучше). 
- 
-<note important>​Если нужно организовать загрузку в режиме SecureBoot, то придется решить еще вопрос и с подписью ядра. Возможны два варианта:​ 
-  * Использовать подписанное Canonical ядро (пакет linux-signed-generic из репозитоиев Ubuntu). В этом случае сертификат от Canonical должен быть помещен в переменную db базы данных ключей UEFI. 
-  * Подписывать ядро своим собственным ключем,​ сертификат (с публичной частью ключа) которого размещен переменной db базы данных ключей UEFI. 
- 
-В первом варианте - для загрузки из UEFI нужно использовать подписанный вариант ядра (vmlinuz*.efi.signed).\\ 
-Во втором варианте нужно организовать (это можно даже автоматизировать) подписывание каждого нового ядра, которое приходит с обновлениями системы. 
-</​note>​ 
- 
-Некоторые сложности может вызвать указание пути к initrd. Ядра выше 3.3 вообще не различают прямые и обратные слеши в параметре initrd, но нужно указать такой путь, что бы ядро смогло найти initrd при загрузки в окружение UEFI. 
- 
-В целом, нам необходимо организовать доступ из UEFI и к ядру, и к initrd (напомню:​ UEFI имеет доступ только к ESP разделу и умеет работать только с файловой системой FAT32). Это может быть решено одним из трех вариантов:​ 
- 
-=== Вариант 1: Загрузить ядро и intrd непосредственно из корневого раздела или раздела boot === 
-Для этого нужно загрузить в UEFI драйвер для поддержки той файловой системы,​ в которую отформатирован ваш корень или /boot. (UEFI "из коробки"​ знает только FAT, драйвера для чтения других FS можно найти [[http://​efi.akeo.ie/​|например тут]]). 
- 
-Вот какие команды надо выполнить в UEFI Shell для загрузки ядра прямо из корня (boot не вынесен в отдельный раздел).\\ 
-- загрузить драйвер поддержки ext2-3-4 (он был предварительно размещен на ESP разделе в каталоге EFI/​drivers) 
-<​code>​load fs0:​\EFI\drivers\ext2_x64.efi </​code>​ 
-<note important>​ВНИМАНИЕ:​ Если UEFI функционирует в режиме SecureBoot, то драйвер также необходимо подписать одним из ключей находящихся в списке ключей db, иначе ему будет отказано в загрузке! </​note>​ 
-- смонтировать корневую FS (эта команда пытается все доступные устройства смапить всеми доступными драйверами) 
-<​code>​map -r</​code>​ 
-- перейти (изменить текущий путь) в новую FS 
-<​code>​fs1:</​code>​ 
-- запустить ядро с параметрами 
-<​code>​vmlinuz root=UUID=0160863a-1468-422b-8bbb-f80e98e3600d ro queit initrd=initrd.img</​code>​ 
- 
-В этом примере я воспользовался тем, что в корне корневой FS автоматически создаются линки на самую свежую версию установленного ядра и его initrd. Перейдя (сменив текущий путь) в корневую ФС мне уже не нужно мудрить с указанием полного пути к ядру и initrd - они находятся в текущем каталоге (из которого и запускается ядро). 
- 
-Все эти действия можно записать в скрипт (для скриптов UEFI Shell принято расширение .nsh), и запускать ОС вызвав его. К сожалению,​ непосредственно скрипт файл нельзя указать как исполняемый файл в пункте меню загрузки UEFI. Согласно спецификации UEFI Shell может исполнить скрипт,​ имя которого передано ему как параметр,​ но мне это сделать не удалось. UEFI Shell может автоматом исполнить (после паузы) скрипт startup.nsh,​ находящийся в корне ESP раздела (можно записать эту последовательность команд туда). 
- 
-Но можно пойти другим путем. Спецификация UEFI поддерживает автоматическую загрузку драйверов. А это собственно и есть то, что нам нужно для того, что бы получить доступ к файловой системе с ядром без скрипта. Однако и тут есть один подводный камень. ​ 
- 
-Дело в том, что просто загрузить драйвер - недостаточно,​ нужно еще вызвать процедуру ремаппинга устройств (т.е. выполнить ту самую команду map -r). При ремапинге каждый драйвер пытается "​прицепиться"​ ко всем доступным устройствам,​ т.е. наш драйвер EXT2-4 сделает доступными все разделы на всех дисках с файловыми системами EXT2-4. 
- 
-Добавить автоматическую загрузку драйвера можно командой bcfg из UEFI-Shell. Следующая команда добавит пункт загрузки Driver0000 (номер задает первый аргумент команды add), который будет загружать драйвер из файла EFI\drivers\ext2_x64.efi (с ESP раздела). Драйвер получит описание "​EXT2-4 Driver":​ 
- 
-<​code>​bcfg driver add 0 EFI\drivers\ext2_x64.efi "​EXT2-4 Driver"</​code>​ 
- 
-Все замечательно и этот драйвер,​ при каждом запуске системы,​ будет загружаться во время инициализации UEFI автоматически,​ но ремапинга не будет. Для того, что бы после загрузки драйвера инициировать ремапинг нужно в опции загрузки драйвера указать специальный атрибут LOAD_OPTION_FORCE_RECONNECT,​ однако ни одной командой UEFI-Shell этот атрибут не установить (по крайней мере мне не удалось найти такой команды). Перелопатив спецификацию UEFI можно понять,​ что нужно то всего прописать значение 3 вместо 1 в первом 32-битном слове UEFI переменной отвечающей за загрузку драйвера (той самой Driver0000, что мы создали командой bcfg). Сделать это изменение можно любым HEX редактором (из загруженной системы),​ запущенным с правами рута, в котором на редактирование открывается файл /​sys/​firmware/​efi/​efivars/​Driver0000-8be4df61-93ca-11d2-aa0d-00e098032b8c (это маппинг в файловую систему sys переменной UEFI). В редакторе нужно байт с адресом 04 поменять с значения 01 на 03 и сохранить файл. 
-<note important>​Я конечно понимаю,​ что такой хакерский метод - это уже просто за гранью разумного для большинства пользователей UBUNTU, но пока мне не удалось найти другого пути задать атрибут LOAD_OPTION_FORCE_RECONNECT в опции загрузки драйвера. </​note>​ 
-После нашей хакерской атаки на UEFI 8-) можно перегрузиться в UEFI-Shell и там прямо при запуске увидеть,​ что все EXT4 разделы уже отмаплены в FS<n> "​диски",​ а значит на них можно сослаться при задании команды загрузки для опции загрузки ОС. 
-В моем примере EXT4 раздел с корневой FS отмапился в FS2. А это позволяет задать в опции загрузки (используя команду bcfg из UEFI-Shell или efibootmgr из загруженной системы) команду такого вида: 
-<​code>​FS2:​\vmlinuz root=UUID=0160863a-1468-422b-8bbb-f80e98e3600d ro queit initrd=FS2:​\initrd.img</​code>​ 
-Если вы все сделали правильно и не забыли подписать драйвер (если у вас включен SecureBoot),​ то поле перезагрузки система успешно должна загрузится прямо с вашего корневого раздела. 
- 
-Несмотря на сложность этого метода в реализации - прелесть его в том, что можно организовать загрузку самого свежего и предыдущего ядер используя только линки в корневой файловой системе (они создаются и обновляются автоматически) и один дополнительный файл на ESP разделе (драйвер). Одновременно,​ это решение максимально использует возможности заложенные в стандарт UEFI. 
- 
-=== Вариант 2: Скопировать ядро и intrd в ESP раздел === 
-Преимущество в том, что не нужно мудрить с организацией поддержки другой FS. Однако,​ каждый раз при обновлении ядра или initrd их нужно вновь копировать в ESP раздел. Решить задачу автоматизации этого процесса можно одним из методов описанных в [[https://​wiki.archlinux.org/​index.php/​EFISTUB#​Alternative_ESP_Mount_Points|этой статье (англ.)]] или подобно тому как это реализовано в проекте [[wiki:​uefiboot|UEFI Boot]]. 
- 
-Вы можете выполнить команду запуска ядра из UEFI Shell, или записать ее в командный файл и запускать его из UEFI Shell, или, воспользовавшись утилитой efibootmgr, записать эту команду как пункт меню загрузки UEFI: 
- 
-<​code>#​ efibootmgr -c -l vmlinuz.efi -u "​root=UUID=0160863a-1468-422b-8bbb-f80e98e3600d ro quiet initrd=initrd"​ -L LinuxKernel 
-</​code>​ 
-Эта команда добавит пункт загрузки LinuxKernel и сделает его первым в списке приоритета загрузки. 
- 
-=== Вариант 3: Смонтировать ESP раздел как /boot === 
-Преимущества этого решения в том, что новые ядра и initrd будут находится (устанавливаться и обновляться) прямо на ESP раздел (который станет одновременно boot разделом). Правда,​ неприятность в том, что название файла с ядром и initrd есть версия,​ и для каждого нового ядра нужно заново прописывать команду в пункт загрузки UEFI. Можно, конечно,​ переименовать в короткие имена (которые однократно будут записаны в пункты загрузки UEFI), однако переименование приводит нас к ситуации близкой к предыдущему случаю - initrd будет при обновлении снова получать номер версии и его каждый раз придется переименовывать. Воспользоваться автоматически создаваемыми ссылками в корневом разделе - не получится (они останутся в файловой сиcтеме корневого раздела,​ к которому нет доступа без доп. драйверов),​ а создать ссылки на FAT разделе - невозможно (этого FAT просто не умеет от рождения). 
- 
-Команда для записи пункта загрузки UEFI через утилиту efibootmgr не отличается принципиально от той, что указана для способа с копированием ядра в ESP раздел:​ 
-<​code>#​ efibootmgr -c -l vmlinuz-3.12.0-22-generic -u "​root=UUID=0160863a-1468-422b-8bbb-f80e98e3600d ro quiet initrd=initrd.img-3.12.0-22-generic"​ -L Ubuntu-3.12.0-22-generic 
-</​code>​ 
-Более детальная проработка этого варианта описана в отдельной статье [[wiki:​uefiboot|UEFI Boot]]. Там реализовано автоматическое обновление пунктов загрузки 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>​ 
- 
-===== Полезные утилиты для UEFI ===== 
-В стандартных репозиториях Ubuntu есть несколько полезных пакетов с утилитами для работы с настройками UEFI. 
-  * efibootmgr - утилита,​ которой можно менять настройки загрузки UEFI, в частности:​ настраивать приоритет загрузки,​ создавать/​изменять/​удалять загрузочные записи UEFI. 
-  * efivar - простая утилита для работы с переменными UEFI. 
-  * efitool - набор утилит и efi-приложений для работы с ключами/​сертификатами,​ используемыми при загрузке в режиме Secure Boot. 
-  * sbsigntool - утилиты для подписывания и проверки подписей UEFI-приложений,​ для организации загрузки в Secure Boot режиме. 
-У всех этих утилит есть вполне толковые man-руководства и есть примеры использованию в Интернете,​ поэтому я не стану останавливаться на деталях использования этих утилит. 
- 
- 
-===== :) Патч Бармина живе всех живых ===== 
-Ну и напоследок,​ последняя "​веселая"​ история связанная с бородатым (по некоторым сведениям 1996 года рождения) [[https://​lurkmirror.ml/​Rm_-rf|патчем Бармина]]. 
- 
-В конце января 2016 некий арчевод решил посмотреть - как работает этот известный патч. 
-И он старательно вписал в команду даже специальный ключ, без которого этот патч уже не запускается... Ну... и получил кирпич из своего MCI нетбука - он даже после сброса не включился! 
- 
-Как нетрудно догадаться корень беды - в кривой прошивке UEFI. Патч вытер вместе с корнем еще и переменные UEFI в NVRAM, которые монтируются в /​sys/​firmware/​efi/​efivars/,​ но принципиально это не могло быть проблемой,​ потому как стандартом UEFI предусматривается нарушение целостности данных в NVRAM: при обнаружении такой ситуации прошивка ОБЯЗАНА осуществить инициализацию NVRAM до состояния настроек по умолчанию/​фабричных (Factory Default). 
-Но вот в MCI решили забить на проверку целостности NVRAM, и незадачливый арчевод потащил свой <​del>​нетбук</​del>​ кирпич в сервис.  ​ 
- 
-После этой новости состоялся [[https://​github.com/​systemd/​systemd/​issues/​2402|наезд]] на разработчиков SystemD (ну на них многие любят наезжать и ругаться,​ а те собственно сами довольно часто дают повод для вполне обоснованной и справедливой ругани в свой адрес):​ мол какого лешего,​ SystemD монтирует эти переменные с возможностью записи!?​ Давайте типа быстро переделайте на монтирование в режиме только-чтение. На что был дан резонный ответ - доступ на запись нужен утилитам,​ и разрешена запись только руту, который при желании премонтирует эти переменные в режиме записи. Так что, это не защитит от <​del>​идиотов</​del>​ <​del>​дураков</​del>​ "​умников",​ которые экспериментируют с патчем Бармина. 
- 
-Самое же примечательное в этой ситуации ИМХО в том, что 20 лет назад отпущенная шутка, до сих пор стреляет,​ да еще с невиданной доселе мощью. 8-) 
- 
-  
-===== Ссылки ===== 
-[[http://​forum.ubuntu.ru/​index.php?​topic=167665.0|Обсуждение на форуме]] \\ 
-[[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://​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 (к сожалению не полностью переведенная на русский язык)]] ​