Update initramfs что это

Ubuntu не загружается дальше initramfs

Пользователи, которые любят экспериментировать со своей операционной системой время от времени сталкиваются с ошибкой загрузки, когда система выводит приглашение ввода BusyBox с initramfs. Эта ошибка означает, что ядро не может загрузить корневой раздел, та файловая система, к которой у вас есть доступ из этого режима не имеет ничего общего с вашей системой. Это содержимое образа initramfs, которое содержит только самые необходимые компоненты, используемые ядром для загрузки системы.

В этом режиме будет сложно что-то исправить, но можно попытаться понять где находится причина проблемы. В этой статье мы рассмотрим что делать если Linux не загружается с initramfs. Такой проблеме подвержены все дистрибутивы, но мы рассмотрим решения на примере Ubuntu.

Почему Linux не загружается дальше initramfs

Если вы столкнулись с данной ошибкой, то после нескольких десятков секунд загрузки увидите такое сообщение:

1. Неверный корневой раздел в загрузчике

В данном случае она сообщает, что не может найти раздел /dev/sda10:

Alert: /dev/sda10 does not exist. Dropping to a shell

Очень часто такая ошибка возникает после манипуляций с разделами дисков, особенно изменения их размера. UUID диска меняется и ядро больше не может его найти. Вы можете посмотреть доступные в системе разделы с помощью команды:

В этом окружении есть BusyBox, а значит есть большинство утилит Unix. Вы можете примонтировать каждый из этих разделов с помощью команды mount и узнать где находится ваш новый корневой раздел, например:

mkdir /mnt
mount /dev/sda5 /mnt
ls

Вы также можете узнать здесь же UUID данного раздела диска, для этого выполните:

В данном случае, корневой раздел имеет имя /dev/sda5. Именно это имя можно передать ядру в конфигурации загрузчика Grub, а можно UUID, но если в этом нет крайней необходимости, то короткое имя использовать гораздо проще. Надо перезагрузить компьютер, в меню Grub выбрать нужную загрузочную запись и нажать клавишу E:

Далее найти пункт, начинающейся со слова linux и в нём параметр root. Его значение вместе со словом UUID надо стереть, а вместо него прописать имя корневого раздела:

После этого система загрузится, а вам останется только создать новый конфигурационный файл grub с помощью команды:

2. Повреждённая файловая система

Подобная ошибка может появляться также при серьезных ошибках в файловой системе, которые мешают примонтировать корневой раздел. Обычно, fsck восстанавливает файловую систему автоматически, но если проблема серьезная и грозит потерей данных, утилите надо подтверждение пользователя для работы. Тогда система показывает такую ошибку:

The root filesystem on /dev/sda5 requires a manual fsck

Вы можете прямо здесь же попытаться восстановить файловую систему. Для этого выполните:

Выводы

В этой статье мы разобрались что делать если в Linux не загружается initramfs, как посмотреть сообщение об ошибке, а также как устранить самые распространённые причины.

Источник

Глава 5. initramfs

Содержание

В этой главе мы рассмотрим зачем нам в действительности требуется initramfs и почему она важна в общем процессе запуска. Иы знаем, что initramfs загружается в память самим начальным загрузчиком, но мы пока не обсуждали как выделяется initramfs. Данная глава адресована этому. Мы также рассмотрим все этапы выделения, повторной сборки и персонализации initramfs. Затем мы рассмотрим собственно структуру initramfs, а также соответствующую последовательность запуска внутри initramfs.

Зачем требуется initramfs?

основная цель процедуры запуска состоит в представлении своему пользователю его собственных файлов, которые размещены в общей корневой файловой системе. Иными словами, именно для имеющегося ядра в обязанности входят поиск, монтирование и представление такой корневой файловой системы своему пользователю. Для достижения этой цели наше ядро обязано запустить соответствующий исполняемый файл systemd, который, опять же, располагается в корневой файловой системе своего пользователя. Теперь это становится задачей курицы и яйца. Для запуска процесса systemd прежде всего нам требуется смонтировать необходимую корневую файловую систему, а для монтирования такой корневой файловой системы нам придётся запустить systemd из его корневой файловой системы. К тому же, помимо этой реальной корневой файловой системы пользователи могут обладать файлами в некоторых прочих файловых системах, таких как NFS, CIFS и т.п., а этот перечень прочих файловых систем также внутри устанавливаемой корневой файловой системы ( /etc/fstab ).

Допустим, наша корневая файловая система расположена в NFS и нет никакого понятия об initramfs. Это означает, что наше ядро обязано смонтировать необходимую корневую файловую систему пользователя в самом себе из NFS. В таком случае, наше ядро должно осуществить следующие задачи:

поднять собственный первичный сетевой интерфейс.

Вызвать некого клиента DHCP и получить со своего сервера DHCP некий IP адрес.

Отыскать необходимый совместный ресурс NFS и связанный с ним сервер NFS.

Смонтировать этот совместный ресурс NFS (свою корневую файловую систему).

Теперь, предположим, наша корневая файловая система находится на устройстве программного RAID. Тогда наше ядро обязано выполнить такие задачи:

Теперь, допустим, наша корневая файловая система расположена в неком логическом томе. Тогда для нашего ядра требуется покончить со следующими задачами для самого себя:

наконец, после того как необходимый root lv заполнен, смонтировать его в качестве корневой файловой системы.

Давайте предположим, что наша корневая файловая система находится на зашифрованном блочном устройстве. В этом случае нашему ядру придётся завершить следующие задачи:

Получить некий пароль от самого пользователя и/ или со вставленного аппаратного маркера (такого как смарт- карта или некий ключ безопасности USB).

Создать некую расшифрованную цель при помощи надлежащего устройства соответствия.

для получения всего этого нашему ядру необходимы исполняемые файлы, относящиеся к LUKS.

Для ядра не представляется возможным включать в себе возможности всех таких корневых файловых систем; следовательно, разработчики пришли к понятию initramfs, чья единственная цель состоит в монтировании необходимой корневой файловой системы.

Само ядро всё ещё способно выполнять все только что обсуждённые нами этапы. Например, если вы соберёте простую систему Linux командной строки из LFS, вам не понадобится монтировать некую корневую файловую систему, поскольку ядро само по себе достаточно в состоянии смонтировать необходимую файловую систему. Однако в тот момент, как вы попробуете добавить в неё GUI через BLFS, вам потребуется initramfs.

Это испортит основной повод исполняемого самого файла ядра.

Исполняемый файл такого ядра будет гигантским в размере. Чем большим размером будет обладать исполняемый файл, тем сложнее его сопровождение.

Такой громадный исполняемый файл сложный в поддержке, обновлении, совместном использовании и обработке в серверах (с точки зрения пакетов RPM).

Источник

Оптимизация initramfs в Debian

Debian Linux это один из самых популярных современных дистрибутивов, являющийся кроме того «родителем» целого ряда других дистрибутивов, в частности Ubuntu, Linux Mint и проч. Популярность Debian завоевал благодаря своей дружественности к пользователю.

Однако у этой дружественности есть и ряд минусов: попытка «угодить всем» привела к тому, что далеко не все элементы системы с конфигурацией по умолчанию работают оптимально. Например образ initramfs занимает на диске почти десять мегабайт и содержит в себе практически все доступные модули, что конечно же в условиях конкретной задачи является излишним.

Далее будет предпринята попытка максимально подробно разобрать способ генерации initramfs в Debian и показать как можно его оптимизировать.

Прежде чем продолжить нужно сделать два уточнения. Первое: все описанные здесь инструкции справедливы не только для Debian, но и для большинства его «потомков». Второе: да, конечно, если пересобрать ядро руками то можно вообще отказаться от initramfs, но не все и не всегда хотят при каждом обновлении заново пересобирать ядро. Поэтому лучше просто оптимизировать initramfs штатными средствами дистрибутива.

Образ initramfs создаётся утилитой update-initramfs. Пронаблюдать как создаётся образ для текущего ядра с настройками по умолчанию можно запустив создание этого образа командой:

Следует отметить что если в образе initramfs отсутствует какой-то модуль то он будет загружен позже, уже с жёсткого диска (главное чтобы набор модулей в образе позволял ядру добраться до этого жёсткого диска).

Основные настройки update-initramfs расположены в директории /etc/initramfs-tools. Начнём со списка загружаемых модулей. Чтобы загружать только нужные изменим значение параметра MODULES в файле initramfs.conf:

Затем пересоздадим образ initramfs, предварительно удалив старый:

Желающие могут сравнить размеры файлов /boot/initrd.img-* до и после этой команды и, так сказать, «почувствовать разницу».

С модулями вобщем-то разобрались. Переходим к хукам. Системные хуки хранятся в директории /usr/share/initramfs-tools/hooks, пользователь (вернее администратор системы) может определять свои хуки в директории /etc/initramfs-tools/hooks (по умолчанию в ней пусто).

Чтобы понять какой хук за что отвечает проще всего выяснить какому пакету он принадлежит и читать документацию на этот пакет. Получить список пакетов-владельцев хуков можно командой:

К сожалению при генерации образа initramfs нельзя указать список хуков, которые надо пропустить. Поэтому единственным способом убрать лишнее из initramfs является удаление пакета, содержащего не нужный хук. Ну или удаление файла хука (однако следует помнить что в этом случае при обновлении системы он будет создан заново).

Хуки принадлежащие initramfs-tools и udev лучше не трогать. С остальными нужно разбираться по ситуации. Например если речь о сервере то вряд ли там используются какие либо файловые системы, монтируемые через fuse, а значит хуки fuse_utils И ntfs_3g явно лишние. Освободить initramfs от них можно следующим образом:

Отдельного внимания заслуживает вопрос явной пересборки образа после внесения каких либо изменений в его конфигурацию, ведь после установки/удаления пакетов, меняющих эту конфигурацию dpkg сам вызывает update-initramfs для обновления образа. Дело в том, что dpkg запускает update-initramfs командой:

При обновлении образа может остаться какой-то не нужный мусор, поэтому лучше всё-таки собирать образ с нуля, что и делается командой:

Источник

Initramfs/Руководство

Все больше и больше систем требуют initramfs для правильной загрузки. В этом руководстве будет рассмотрены основные понятия initramfs, а также как правильно создать и управлять initramfs на отдельных примерах.

Contents

Основные понятия initramfs

Введение

Для большинства пользователей initramfs не является чем-то необходимым. Их система использует простую схему разбиения жесткого диска без экзотических драйверов или установок (таких как зашифрованные файловые системы), поэтому ядро Linux вполне способно передать управление двоичному файлу init на их системе. Но для большинства систем, использование initramfs почти обязательно.

Процесс загрузки Linux

Для систем, где все необходимые файлы и инструменты располагаются на той же самой файловой системе, приложение init может в совершенстве управлять дальнейшим процессом загрузки. Но когда определены множественные файловые системы (или в случае более неординарных установок), этот процесс может стать немного более усложненным:

С давних пор решением для этой проблемы является использование «initrd» (initial root device).

Корневой диск для начальной инициализации (initial root disk)

Чтобы решить эти вопросы, была создана initramfs.

Файловая система в памяти для начальной инициализации (initramfs)

Содержимое initramfs делается путем создания cpio-архива. cpio — это старое (но проверенное) решение для архивирования файлов (архивы, получаемые в результате его работы называются cpio-архивы). Безусловно cpio можно сравнить с tar архиватором. Здесь cpio был выбран потому, что проще создать (с программной точки зрения) и поддерживать (на то время) файлы устройств (тогда как tar этого не мог).

Все файлы, утилиты, библиотеки, настройки конфигурации (если они применимы), и т.д. помещаются в cpio-архив. Этот архив затем сжимается с использованием утилиты gzip и сохраняется в том же месте, что и ядро Linux. Далее, загрузчик передаст его ядру Linux во время загрузки, чтобы ядро знало о том, что требуется initramfs.

Создание initramfs

Введение и настройка загрузчика

Использование genkernel

Чтобы использовать genkernel для генерации initramfs, рекомендуется все необходимые драйверы и код, который требуется для монтирования / и /usr файловых систем, включить в ядро (а не как модули). Затем, вызвать команду genkernel следующим образом:

В зависимости от системы, одна или более из следующих опций могут быть необходимы:

Использование dracut

Утилита dracut создана с единственной целью управления файлами initramfs. Она использует весьма модульный подход в плане выбора поддержки; что требуется включить, а что нет.

Рекомендуется установить (или убрать) необходимые модули. После настройки переменной DRACUT_MODULES в файле /etc/portage/make.conf запустите команду emerge dracut для установки утилиты Dracut.

После конфигурации, создайте initramfs вызовом dracut следующим образом:

Чтобы найти больше информации, проконсультируйтесь с man-страницами:

Источник

Используем Secure Boot в Linux на всю катушку

Технология Secure Boot нацелена на предотвращение исполнения недоверенного кода при загрузке операционной системы, то есть защиту от буткитов и атак типа Evil Maid. Устройства с Secure Boot содержат в энергонезависимой памяти базу данных открытых ключей, которыми проверяются подписи загружаемых UEFI-приложений вроде загрузчиков ОС и драйверов. Приложения, подписанные доверенным ключом и с правильной контрольной суммой, допускаются к загрузке, остальные блокируются.

Более подробно о Secure Boot можно узнать из цикла статей от CodeRush.

Чтобы Secure Boot обеспечивал безопасность, подписываемые приложения должны соблюдать некоторый «кодекс чести»: не иметь в себе лазеек для неограниченного доступа к системе и параметрам Secure Boot, а также требовать того же от загружаемых ими приложений. Если подписанное приложение предоставляет возможность недобросовестного использования напрямую или путём загрузки других приложений, оно становится угрозой безопасности всех пользователей, доверяющих этому приложению. Такую угрозу представляют загрузчик shim, подписываемый Microsoft, и загружаемый им GRUB.

Чтобы от этого защититься, мы установим Ubuntu с шифрованием всего диска на базе LUKS и LVM, защитим initramfs от изменений, объединив его с ядром в одно UEFI-приложение, и подпишем его собственными ключами.

Ограничения решений «из коробки»

Ubuntu, как и другие распространённые дистрибутивы, предлагает опцию шифрования всего диска с LVM во время установки. Дистрибутив в такой конфигурации без ошибок устанавливается на UEFI с активным Secure Boot.

Но Canonical в первую очередь заинтересована в работоспособности ОС на устройствах с включённым Secure Boot, а не в обеспечении безопасности за счёт него. Если вы хотите использовать Secure Boot как средство безопасности, то вы сами по себе.

Как Ubuntu реализует загрузку в Secure Boot с шифрованием всего диска и что с этим не так?

Red Hat разработали загрузчик shim, чтобы он работал на всех устройствах и служил на благо человечеству, соблюдая строгие предписания стандарта Secure Boot и загружая только доверенные UEFI-приложения. Canonical использует shim как прокси, встраивая в него свой публичный ключ и подписывая у Microsoft. Shim загружает GRUB, подписанный ключём Canonical, который затем загружает ядро, подписанное Canonical.

Начнём с того, что шифруется не весь диск — /boot остаётся незашифрованным, а значит и initramfs в нём. Доступ к initramfs означает root-доступ. Fail.

GRUB должен верифицировать загружаемые ядра и отвергать неверно подписанные. Он этого не делает. Triple Fail.

Что это всё означает?

Согласно политике Microsoft о подписывании UEFI-приложений, все подписанные загрузчики GRUB и shim, используемые для загрузки GRUB, уже должны быть занесены в чёрный список.

Вывод

Необходимо отказаться от чужих ключей. Пользователь должен контролировать Secure Boot. Загрузчик должен быть подписан пользователем, все незашифрованные и доступные для записи элементы в загрузке системы должны верифицироваться. Пользовательские данные должны быть зашифрованы. Чего мы и попытаемся добиться.

Установка Ubuntu с шифрованием всего диска с помощью LUKS и LVM

LUKS — Linux Unified Key Setup — обёртка для криптографической системы dm-crypt, позволяющая создавать виртуальные зашифрованные устройства в файлах и на физических дисках. С помощью LUKS можно зашифровать данные на всём диске для того, чтобы перед загрузкой ОС требовалось ввести пароль.

LVM — Logical Volume Manager — менеджер логических томов, с помощью которого мы разделим криптоконтейнер на тома. Тома LVM автоматически монтируются после ввода пароля к криптоконтейнеру, отдельный ввод пароля для каждого тома не требуется.

Следующие инструкции должны быть применимы к любому дистрибутиву на базе Ubuntu, для других потребуются коррективы. Сперва загрузитесь с Live CD или установочного образа в режиме Try before installing.

Разметка и шифрование

Чтобы загружаться с диска в режиме UEFI, он должен быть размечен в формате GPT. Разметку диска рассмотрим с помощью KDE Partition Manager и GParted. Если у вас их нет, установите один, соответствующий вашей среде.

Запустите редактор разделов и выберите интересующий вас диск, обычно это первый в системе — /dev/sda. Посмотрите свойства диска.

В строке Partition table указана используемая таблица разделов. Если диск размечен в формате dos/msdos (MBR), то его необходимо преобразовать в GPT. Это возможно сделать без потери данных, но здесь я этого описывать не буду, поищите инструкции в интернете. Если на диске нет важных данных и вы хотите форматировать его в GPT, создайте новую таблицу.

На диске должен быть как минимум один раздел ESP (EFI System Partition), в котором будут храниться загрузчики. Если на этом диске установлена ОС в режиме UEFI, то один такой раздел уже есть. В любом случае я рекомендую создать новый размером не меньше 100 МБ. ESP должен быть отформатирован в один из FAT-форматов, предпочтительно в FAT32, а также помечен как загрузочный.

Дальше нужно создать раздел для шифрования. Тем же образом, что и ESP, только без форматирования (unformatted), выставления флагов и размером побольше — так, чтобы вместил систему и раздел подкачки. Создадим в этом разделе криптоконтейнер LUKS через терминал, предварительно перейдя в режим суперпользователя.

Подтвердите форматирование, написав YES, введите пароль. Теперь откройте криптоконтейнер (sda2_crypt — имя для маппинга) и введите тот же пароль.

Контейнер должен стать доступным как блочное устройство /dev/mapper/sda2_crypt. Перейдём к разметке логических томов внутри криптоконтейнера. Инициализируем физический раздел LVM поверх /dev/mapper/sda2_crypt.

Внутри этого физического раздела создадим группу томов с именем ubuntu.

Теперь мы можем создавать логические тома внутри этой группы. Первым делом создадим том для раздела подкачки и инициализируем его. Рекомендуемый размер — от sqrt(RAM) до 2xRAM в гигабайтах.

С разметкой закончено, можно перейти к установке.

Установка

Так как мы планируем создать загрузчик самостоятельно, да и установщик Ubuntu не поддерживает шифрование /boot, запустим установку без создания загрузчика.

На этапе разметки диска выберите Вручную.

Здесь нам необходимо указать точки монтирования. Выберите /dev/mapper/ubuntu-root, укажите использование в качестве журналируемой файловой системы Ext4, точку монтирования (Mount Point) в /, без форматирования. Ubiquity сама подхватит /dev/mapper/ubuntu-swap как раздел подкачки и запомнит один из системных разделов EFI. Экран разметки должен выглядеть так:

Закончите установку и не перезагружайтесь.

Настройка crypttab, fstab и resume

Вам необходимо вручную заполнить /etc/crypttab — файл, описывающий монтируемые при загрузке криптоконтейнеры.

В него нужно добавить запись о /dev/sda2, монтируемом в /dev/mapper/sda2_crypt. Настроим монтирование по UUID, а не по имени устройства. Чтобы узнать UUID /dev/sda2, откройте другой терминал и воспользуйтесь командой:

Проверьте, чтобы в /etc/fstab были правильно описаны монтируемые разделы, а в /etc/initramfs-tools/conf.d/resume указан раздел для пробуждения из гибернации.

После всех изменений обновите образ initramfs.

Создание загрузчика

Ядро Linux поддерживает загрузку напрямую из UEFI, если оно было скомпилировано с параметром CONFIG_EFI_STUB. В таком случае initramfs обычно хранится рядом в ESP, и путь к нему передаётся в аргументах к ядру.

Однако отсутствие верификации initramfs позволяет встроить в него вредоносный код, имея доступ на запись в ESP. Teddy Reed предлагает компилировать ядро, встраивая в него initramfs.

Процесс компиляции ядра достаточно длительный, её придётся производить после каждого изменения initramfs. К счастью, есть другой способ. В пакете systemd (ранее в gummiboot ) находится linuxx64.efi.stub — заготовка UEFI-приложения, в которую можно встроить ядро, initramfs и аргументы, передаваемые ядру. Подписав это UEFI-приложение, мы защитим ядро и initramfs от изменений.

Запишем в /tmp/cmdline аргументы, которые будут передаваться ядру.

В /boot хранятся образы ядра (vmlinuz-*-generic) и initramfs (initrd.img-*-generic). Определите последнюю версию и встройте их в заготовку.

Полученное UEFI-приложение ubuntu.efi необходимо расположить в ESP в каталоге EFI/BOOT/. Установщик Ubuntu должен был определить ESP и настроить монтирование в /boot/efi. Если в этом ESP нет других загрузчиков, то ubuntu.efi можно скопировать в /boot/efi/EFI/BOOT/BOOTX64.EFI, тогда он будет загружаться при выборе этого раздела в меню загрузки UEFI.

UPD: Если в вашу прошивку не встроен UEFI Shell, то скачать его можно отсюда. Положите его в EFI/BOOT/BOOTX64.EFI любого ESP и загружайтесь с отключённым Secure Boot. Чтобы добавить загрузочную запись, введите команду:

Спасибо Prototik за ссылку на UEFI Shell. Список остальных команд можно найти здесь.

Если у вас включён Secure Boot, то загрузиться с ubuntu.efi не получится, так как он не подписан. Временно отключите Secure Boot и загрузитесь, либо продолжите из chroot.

Настройка Secure Boot

Генерацию ключей, их установку в прошивку и подписывание UEFI-приложений описал CodeRush здесь, поэтому я буду считать, что вы всё понимаете и умеете.

Остаётся только подписать созданный нами загрузчик.

Поместите BOOTX64.EFI в каталог EFI/BOOT/ раздела EFI, с которого вы планируете загружаться.

Автоматизация

Чтобы загрузчик автоматически обновлялся и подписывался при обновлении initramfs, создайте скрипт update-efi-loader в /etc/initramfs/post-update.d/, изменив пути где требуется.

Дайте скрипту право на исполнение.

При обновлении ядра придётся произвести эту операцию вручную.

Подписывание драйверов и модулей ядра

Чтобы добавить этот сертификат в прошивку, его необходимо преобразовать в формат PEM, затем в ESL и подписать ключом KEK.

Очевидные советы

Если вашей задачей стоит защита данных на устройстве, то Secure Boot выполнит свою работу и не больше. Остальное возлагается на вас.

Не добавляйте чужих ключей в прошивку. Даже от Microsoft. В первую очередь от Microsoft.

Не подписывайте UEFI Shell, KeyTool или другие приложения, имеющие доступ к записи в NVRAM. Используйте их в Setup Mode.

Не оставляйте устройство включённым без присмотра. Устройство в ждущем режиме (suspend to RAM) содержит в RAM расшифрованные данные и мастер-ключи от криптоконтейнеров.

Установите пароль на UEFI Setup не проще, чем от вашего криптоконтейнера.

При физическом доступе к внутренностям устройства можно отключить Secure Boot, сбросив память NVRAM или повредив её, а также оставить хардварную закладку. Такая атака успешна только тогда, когда она незаметна. Сделайте так, чтобы вы о ней могли узнать: заклейте винты на корпусе трудновоспроизводимыми стикерами, обмажьте их лаком с блёстками. Опечатайте своё устройство.

Поставьте первым в списке загрузки неподписанное приложение. Если вы однажды не увидите сообщение от Secure Boot, то ваше устройство однозначно скомпрометировано.

Надёжнее отключённого от интернета устройства, хранимого в сейфе, всё равно ничего не придумаешь. Уязвимости в реализации Secure Boot в конкретных прошивках не исключены.

Бонус: возвращение гибернации

При шифровании всего диска вместо ждущего режима для сохранения состояния и продолжения работы с места остановки обычно используется гибернация, она же спящий режим или suspend to disk.

Из соображений безопасности разработчики ядра отключили возможность гибернации при включённом верифицировании модулей ядра. Аргументируется это тем, что образ восстановления не верифицируется при пробуждении, раздел подкачки может быть подменён и тогда система проснётся с непроверенным и потенциально вредоносным кодом.

Это верно в том случае, если initramfs не верифицируется и/или раздел подкачки не зашифрован. Однако независимо от использования гибернации при таких условиях initramfs может быть подменён, а чувствительные данные восстановлены из раздела подкачки. В нашей конфигурации initramfs верифицируется, будучи включённым в подписанный загрузочный файл, а раздел подкачки зашифрован. Значит, данное ограничение для нас бессмысленно.

Chung-Yi Lee ещё в 2013 предложил верифицировать образ восстановления, а в 2015 представил реализующий его идею патч. Но воз и ныне там. Поэтому предположим, что мы достаточно защищены с нашим шифрованием, и вернём нам гибернацию без верификации.

Способ 1. Отключить верификацию модулей ядра

Включённая верификация модулей ядра отключает гибернацию. По умолчанию верификация модулей ядра включается вместе с Secure Boot, однако она от Secure Boot не зависит. Её можно отключить, оставив только Secure Boot.

Большого ущерба безопасности это нанести не должно. Модули ядра устанавливаются из доверенного источника вместе с обновлением ядра и хранятся на зашифрованном диске и в верифицируемом initramfs. Сторонние драйвера устанавливаются вручную, и будут они подписаны нами или нет, значения не имеет, ведь мы им уже доверяем. SecureApt для ядра и TLS/HTTPS для сторонних драйверов должны защитить от MiTM, и тогда остаётся только root-доступ к расшифрованному диску. Но в таком случае у злоумышленника уже есть наши данные.

Введите пароль, который затем потребуется посимвольно подтвердить. Теперь нужно загрузиться через shim и выбрать в нём Change Secure Boot state (sic!). Поместите /usr/lib/shim.efi в EFI/BOOT/BOOTX64.EFI на одном из ESP или добавьте загрузочную запись через UEFI Shell. Предварительно отключите Secure Boot, после верните обратно.

UPD 12.01.17: Вместе с shim.efi необходимо сохранять рядом и MokManager. В последних версиях пакета shim.efi и MokManager располагаются в /usr/lib/shim/, shimx64.efi и mmx64.efi.signed соответственно. Нужно переименовать mmx64.efi.signed в mmx64.efi.

Сейчас Secure Boot и гибернация работают, UEFI-приложения верифицируются, но модули ядра нет.

В принципе, shim и mokutil больше не требуются, их можно удалить.

Способ 2. Использовать старую версию ядра

Патч, отключающий гибернацию, появился в версии Ubuntu-4.4.0-18.34. Ubuntu-4.4.0-17.33 должна быть от него свободна. Однако оставаться на старом ядре, игнорируя обновления безопасности, не лучший вариант.

Способ 3. Скомпилировать своё ядро

Если ваше время ничего не стоит, то вы можете скомпилировать своё ядро без этого ограничения. Гарантий, что после долгих мучений вы будете довольны результатом, нет. Но если вы этого очень хотите, хвала Линусу Торвальдсу и GPLv2, у вас есть на это право. Вы можете предварительно протестировать скомпилированное мною ядро, чтобы не тратить зря время.

Получение исходного кода

apt-get

Самый простой способ получить исходный код для ядра вашей версии — скачать его из репозитория.

В /etc/apt/sources.list должны присутствовать указатели на репозитории исходных кодов. Обычно там уже есть закомменти­рованные записи с deb-src. Раскомментируйте их для репозиториев xenial main и xenial-security main, либо добавьте сами, а затем обновите индекс apt.

Загрузите исходный код и перейдите в создавшуюся директорию.

Обратите внимание на то, чтобы apt скачивал актуальную версию исходного кода. Проверьте номер версии у файла .dsc.

Если вы хотите поддерживать ядро в актуальном состоянии и перекомпилировать его по мере выхода обновлений с сохранением своих изменений, выберите git. Первоначальная загрузка займёт продолжительное время.

Создайте локальную копию git-репозитория ядра текущего релиза Ubuntu и перейдите в создавшуюся директорию.

Создайте ветку temp для тега, соответствующего вашей версии, и переключитесь на неё.

Настройка

Загрузите пакеты, требуемые для компиляции (build dependencies).

Убедитесь, что скриптам выставлено право на исполнение, запустите чистку.

Скопируйте старый файл конфигурации в текущую директорию, запустите конфигурацию, выберите Load и загрузите config. Больше изменять ничего не требуется, выйдите и сохраните конфигурацию — Exit → Yes.

Измените файл kernel/power/hibernate.c, убрав проверку secure_modules().

Подготовьте файл к коммиту.

Если вы ещё не совершали коммитов и не вводили свои данные, сделайте это сейчас.

Сделайте коммит, введите комментарий.

Теперь ваши изменения сохранены в новом снимке состояния (snapshot). Если вы захотите обновиться до следующей версии и применить к ней те же самые изменения, используйте git rebase

Скрипты компиляции определяют версию ядра по последней записи в истории изменений (changelog) в директории debian.master. Добавьте новую запись, чтобы изменить версию.

К версии будет добавлен суффикс custom1, что отразится при сборке пакетов .deb и позволит установить их при уже установленных пакетах той же версии без суффикса. Однако этот суффикс распространяется только на имя пакета, но не на его содержимое: ядро и директория с его модулями будут иметь ту же версию 4.4.0-34-generic, и при установке старые файлы перезапишутся новыми. Чтобы этого избежать, измените версию ABI c 34 на, например, 3400.

Компиляция

Запустите чистку ещё раз и скомпилируйте ядро. Если вы не опытный разработчик ядра и не понимаете, как работают проверки ABI и модулей (я вот не понимаю), отключите их (skipabi=true, skipmodule=true), иначе ваша компиляция сломается на одном из последних этапов. Здесь используется многопоточная сборка пакетов с количеством потоков, равным количеству ядер процессора. Цель binary-generic означает компиляцию обычной разновидности ядра, архитектура определяется автоматически.

Снова соберите загрузочный файл.

Гибернация работает, но нестабильно. Как, впрочем, и без Secure Boot.

Способ 4. Отказ от гибернации и использование виртуализации

Если гибернация и работает, то это не делает её надёжным средством сохранения состояния. Это может быть проблемой моего железа, дистрибутива или, что более вероятно, KDE Plasma, но у меня Kubuntu просыпается через раз.

С большей надёжностью придёт и большая защищённость: чувствительные данные можно изолировать от опасной среды. Браузер и песочница для установки стороннних пакетов в одной виртуальной машине, важные персональные данные — в другой. Украсть мастер-ключ от зашифрованного диска в памяти хостовой ОС из гостевой гораздо сложнее. Кажется, для подобного существует Qubes OS. Но она данный момент не поддерживает Secure Boot. Fail.

На этом всё, приветствуются любые дополнения и замечания.

Примечания

↑ Теоретически можно исправить, установив пароль, встроив grub.cfg в образ GRUB с помощью grub-mkstandalone и установив в grub.cfg prefix на невалидный путь, чтобы GRUB не мог найти второй grub.cfg на диске. Но опять же требуется подписывать образ самостоятельно.

↑ А он есть у всех кроме параноиков оправданно озабоченных своей безопасностью пользователей.

↑ У меня загрузиться с USB не даёт. Windows 8 и 10 также без пароля не пускают в безопасный режим или консоль.

↑ Говорят, некоторые прошивки он окирпичивает. Безопаснее создать по ESP на каждый загрузчик.

Источник