как узнать включен ли secure boot linux
Как работает Secure Boot в Windows и что это значит для Linux
В современных компьютерах часто вместо старого BIOS установлена UEFI. Во многих UEFI по умолчанию активирована функция безопасной загрузки (Secure Boot). Эта функция, предотвращает загрузку на компьютере не авторизованного ПО, к которому относятся также различные драйверы и ОС. Если производитель компьютера (ноутбука) желает чтобы его изделие было сертифицировано Microsoft и на него можно было наклеить соответствующую наклейку с Windows 10 или 8, режим безопасной загрузки в устройстве должен быть включен. К сожалению, данная возможность может затруднить или вообще сделать невозможной установку на такой компьютер Linux. Давайте разберемся как работает режим Secure Boot и как он влияет на возможность установки на ПК не Windows ОС.
Как Secure Boot защищает процесс загрузки
Обычный BIOS способен загрузить любое ПО. Когда вы включаете свой компьютер, он проводит тест всего оборудования, в случае каких-либо неполадок выдает соответствующее сообщение, а если все в порядке, ищет загрузчик операционной системы и передает управление компьютером ему.
Все просто, но подобный подход позволяет в момент загрузки компьютера запускать и вредоносный код, который после загрузки ОС никак себя не будет выдавать. Для BIOS нет разницы между вредоносным кодом и кодом загрузчика, он загрузить все, что найдёт. Безопасная загрузка создана для того, чтобы избежать подобного.
Компьютеры с предустановленной Windows 8 или 10 имеют специальный, вшитый в UEFI сертификат Microsoft. Когда UEFI находит загрузчик ОС, он проверяет его на наличие подписи Microsoft, и только после этого передает ему управление. Если какой-либо вирус или другой вредоносный код подменит загрузчик, UEFI не позволит ему загрузится.
Каким образом Microsoft позволяет загружаться Linux с Secure Boot
Кроме того, для Linux дистрибутивов есть несколько уже подписанных загрузчиков. Например Shim. Это небольшой загрузчик, предназначение которого передать загрузку основному загрузчику, GRUB, к примеру. Поскольку Shim подписан колючем от Microsoft, он без проблем проходит проверку UEFI, в свою очередь загружая подписанный Linux дистрибутивом загрузчик. Затем Linux загружается в обычном режиме.
Такие дистрибутив как Ubuntu, Fedora, RHEL и openSUSE без проблем поддерживают режим безопасной загрузки, поэтому без особых трудностей будут работать на любом современном железе. Однако есть также некоторые дистрибутивы, которые, следуя своей философии, не подписывают ПО ключами от Microsoft. Поэтому при выборе компьютера или дистрибутива это стоит учитывать.
Управление режимом Secure Boot
Если из-за режима безопасной загрузки вы не можете использовать свой любимый дистрибутив, существует несколько способов решить эту проблему.
Первый, и самый простой способ — отключение Secure Boot. Это можно сделать в настройках UEFI. После этого UEFI перестанет проверять подпись запускаемого ПО, и вы сможете, как и при старом BIOS, загружать любой дистрибутив.
Второй способ — настройка Secure Boot. Можно управлять тем, что режим безопасной загрузки должен проверять. Пользователь может сам устанавливать новые сертификаты и удалять уже вшитые. Например, можно удалить все сертификаты Microsoft и установить свои.
Как узнать включен ли secure boot linux
В общем учитывая статью в особенности секцию Using the Shim Program подтвердите или опровергните мои опасения.
In early 2017, Secure Boot is a modest-to-major hassle for Linux users. Although Secure Boot has the potential to improve security, Linux has historically not been plagued by viruses, so it’s unclear that Secure Boot will be a benefit for Linux-only computers. If you dual-boot with Windows, though, you may want to keep Secure Boot enabled. Using the Shim program looks like the best way to do this for users of Fedora, OpenSUSE, Ubuntu, and other distributions that support Shim. If you’re using another distribution or are having trouble booting multiple distributions, disabling Secure Boot is the easiest way to deal with it. Signing your own boot loaders to use the native Secure Boot mechanism and your own key set is another alternative, and one that provides you with the greatest security and flexibility. This approach is the hardest one to implement, particularly if your computer’s firmware setup utility lacks the ability to add keys..
UEFI. Сделка с Secure Boot
UEFI. Сделка с Secure Boot
Похоже, что у Вас какая-то странная реализация UEFI (по крайней мере, впервые с таким сталкиваюсь), которая позволяет даже при включенном Secure Boot загружать неподписанные загрузчики. Иначе как Вы установили Минт (см. ниже)? Вообще, если он (Secure Boot) у Вас действительно работает так и это нельзя изменить, толку от него ноль.
Secure Boot работает следующим образом: у EFI-приложения (обычно это загрузчик ОС) проверяется цифровая подпись, и если она соответствует ключу из хранилища, то выполнение этого приложения разрешается. Таким образом исключается возможность загрузки недоверенных приложений и подмены доверенных.
Теперь о проблемах такого подхода. По умолчанию на всех компьютерах с Secure Boot в хранилище есть лишь ключ Microsoft, который используется для загрузки Windows.
Вообще для того, чтобы подменить загрузчик, нужны права суперпользователя либо физический доступ к машине. Защищают, как правило, личные файлы, а не саму ОС, так что в этих двух случаях уже плевать, что там с загрузчиком сталось.
Подводя итог: обычному пользователю включенный Secure Boot ни к чему и будет только мешать. Если же пользователь — параноик и действительно заботится о безопасности своих данных, то доверять Майкрософту он не будет, а сгенерирует и установит свои ключи, удалив все остальные.
UEFI. Сделка с Secure Boot
Пара картинок.
то что у меня сейчас (слил в один файл я думаю понятно)
UEFI. Сделка с Secure Boot
А по поводу возможности заражения… Я далеко не эксперт в области информационной безопасности, но некоторую ясность попытаюсь внести, исходя из своего опыта.
До сих пор я ни разу не видел вредоносов, которые подменяют загрузчик в UEFI, так как реализовать это при включенном Secure Boot даже с учётом утечки ключа сложновато. Во времена BIOS подменяли загрузочную запись в MBR, и сделать это было довольно просто, хотя толку немного. Так как личные данные для пользователей стоят на первом месте, сейчас чаще всего используют шифровальщики-вымогатели: файлы с определёнными расширениями (текст, документы Microsoft Office, изображения (фотографии) и т. п.) шифруются стойким алгоритмом, и у пользователя вымогают деньги, обещая после выплаты выдать программу для расшифровки. Так как подавляющее большинство пользователей не делает бэкапы, это, пожалуй, самые эффективные вредоносы на сегодняшний день. Таким образом, если где и подменяют загрузчик, то разве что на крупных серверах, встраивая туда rootkit. Обычным пользователям это не грозит, ведь написать руткит не так-то просто, а взять с них всё равно нечего. Заражают саму систему, как правило, для того, чтобы дёшево или вообще бесплатно собрать ботнет для DDoS-атак на крупные ресурсы. Для пользователя в таком случае из последствий лишь излишние нагрузка на процессор и сетевой трафик, но и только.
Другой пример. В Steam долгое время не было приложения-аутентификатора, и Steam Guard работал только через отправку сообщения на почту с кодом подтверждения. Сейчас, к счастью, такую возможность добавили. Но на тот момент, когда произошёл случай, о котором я сейчас расскажу, её не было.
Итак, одному моему знакомому (назовём его Вася) написал незнакомец. Долгое время втирался в доверие и, наконец, предложил вместе сыграть. Вася хотел созвониться по Скайпу, но тот человек отказался, настояв на использовании другой голосовухи. Точно уже не помню, какой, но малоизвестной. Собственно, дал ссылку на сайт и предложил скачать. Вася, ничего не подозревая, так и сделал, потому что сайт выглядел вполне серьёзным. При установке программа запросила права администратора (UAC), что вполне ожидаемо, ведь большая часть программ устанавливается общесистемно. Поэтому Вася дал разрешение. Однако, на деле ничего не установилось, и вскоре Вася заметил, что весь его инвентарь в Стиме бесследно исчез.
Итог: заражение загрузчика — очень маловероятный сценарий. Лучший способ себя обезопасить — это быть внимательнее и никому не доверять вслепую (даже знакомым, ведь и их могут взломать). Антивирус — не панацея, UAC и ограниченная учётка — тоже. Они лишь уменьшают риск, но не убирают его полностью. Также очень желательно делать бэкапы во избежание потери данных и использовать двухфакторную аутентификацию, чтобы в случае угона пароля злоумышленник всё равно не мог войти в аккаунт.
UPD: чуть дополню. Многое из этого относится и к Линуксу тоже. Пусть даже он гораздо менее популярен, чем Винда, но никто не мешает использовать те же самые приёмы, если злоумышленник осведомлён о том, что целевой пользователь — линуксоид. К тому же, есть вредоносы, написанные так, что работают сразу под несколькими ОС. Так что это тоже не панацея. 
Используем 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 на каждый загрузчик.