configuring secure boot ubuntu что делать
Почему меня попросили создать пароль для отключения безопасной загрузки при начальной установке Ubuntu 16.04?
При первоначальной установке Ubuntu 16.04 я установил флажок «Установить стороннее программное обеспечение», и под ним мне предложили отметить другой параметр, который позволял бы пакету ОС автоматически отключать безопасную загрузку самостоятельно, обязательным условием которого было создание пароля, который каким-то образом позволил бы всему этому процессу произойти.
После продолжения установки мне никогда не давали никаких указаний на то, что произошло отключение безопасной загрузки, и мне никогда не предлагалось ввести созданный мной пароль.
После успешной установки ОС я перезагрузил компьютер и проверил BIOS. В BIOS безопасная загрузка все еще была включена. Однако, вернувшись в Ubuntu, я могу без проблем воспроизводить файлы MP3 и Flash, что, как я полагаю, указывает на успешную установку стороннего программного обеспечения.
Я еще не сталкивался с какими-либо проблемами (за исключением того факта, что пользовательский интерфейс иногда был немного привередлив и глючил), но я хотел бы знать, чего на самом деле я достиг, создав этот пароль.
Что случилось с паролем, который я создал? Нужно ли будет помнить это по какой-либо причине? Это не то же самое, что мой логин / пароль sudo.
Ubuntu постоянно редактировал мой BIOS, чтобы сделать для себя исключение? Если да, как я могу просмотреть эти изменения и, возможно, отменить их? Это где пароль будет входить?
Почему Ubuntu все равно нужно отключить / пропустить безопасную загрузку, чтобы установить пакет ubuntu-limited-extras? Моя установка в порядке? Я настроился на будущие проблемы? Должен ли я попробовать переустановить с отключенной безопасной загрузкой вручную, чтобы не получать это приглашение?
Дополнительная информация: Я использую систему UEFI и работаю с двойной загрузкой Ubuntu 16.04 вместе с Windows 10.
Другой пользователь задал вопрос о подобной проблеме здесь. В отличие от этого пользователя, я не получаю предупреждение о «загрузке в небезопасном режиме», но я также хотел бы знать, создал ли Ubuntu исключение для себя и как я могу управлять такими исключениями. В отличие от меня, этот пользователь не упомянул ничего о необходимости создания пароля.
Ubuntu Wiki
SecureBoot
What is UEFI Secure Boot?
UEFI Secure boot is a verification mechanism for ensuring that code launched by firmware is trusted.
Proper, secure use of UEFI Secure Boot requires that each binary loaded at boot is validated against known keys, located in firmware, that denote trusted vendors and sources for the binaries, or trusted specific binaries that can be identified via cryptographic hashing.
Most x86 hardware comes from the factory pre-loaded with Microsoft keys. This means we can generally rely on the firmware on these systems to trust binaries that are signed by Microsoft, and the Linux community heavily relies on this assumption for Secure Boot to work. This is the same process used by Red Hat and SUSE, for instance.
Many ARM and other architectures also support UEFI Secure Boot, but may not be pre-loading keys in firmware. On these architectures, it may be necessary to re-sign boot images with a certificate that is loaded in firmware by the owner of the hardware.
Initial implementation plan: Implementation Plan.
Supported architectures
amd64: A shim binary signed by Microsoft and grub binary signed by Canonical are provided in the Ubuntu main archive as shim-signed or grub-efi-amd64-signed.
arm64: As of 20.04 (‘focal’), a shim binary signed by Microsoft and grub binary signed by Canonical are provided in the Ubuntu main archive as shim-signed or grub-efi-arm64-signed. There is a GRUB bug under investigation that needs to be resolved before this works end to end.
Testing UEFI Secure Boot
If you’re interested in testing Secure Boot on your system, consult the how-to here: UEFI/SecureBoot/Testing.
How UEFI Secure Boot works on Ubuntu
On Ubuntu, all pre-built binaries intended to be loaded as part of the boot process, with the exception of the initrd image, are signed by Canonical’s UEFI certificate, which itself is implicitly trusted by being embedded in the shim loader, itself signed by Microsoft.
On architectures or systems where pre-loaded signing certificates from Microsoft are not available or loaded in firmware, users may replace the existing signatures on shim or grub and load them as they wish, verifying against their own certificates imported in the system’s firmware.
As the system boots, firmware loads the shim binary as specified in firmware BootEntry variables. Ubuntu installs its own BootEntry at installation time and may update it any time the GRUB bootloader is updated. Since the shim binary is signed by Microsoft; it is validated and accepted by the firmware when verifying against certificates already present in firmware. Since the shim binary embeds a Canonical certificate as well as its own trust database, further elements of the boot environment can, in addition to being signed by one of the acceptable certificates pre-loaded in firmware, be signed by Canonical’s UEFI key.
The next thing loaded by shim is the second-stage image. This can be one of two things: either GRUB, if the system is booting normally; or MokManager, if key management is required, as configured by firmware variables (usually changed when the system was previously running).
If booting normally; the GRUB binary (grub*.efi) is loaded and its validation is attempted against all previously-known trusted sources. The GRUB binary for Ubuntu is signed by the Canonical UEFI key, so it is successfully validated and the boot process continues.
If booting to proceed with key management tasks, the MokManager binary (mm*.efi) is loaded. This binary is explicitly trusted by shim by being signed by an ephemeral key that only exists while the shim binary is being built. This means only the MokManager binary built with a particular shim binary will be allowed to run and limits the possibility of compromise from the use of compromised tools. MokManager allows any user present at the system console to enroll keys, remove trusted keys, enroll binary hashes and toggle Secure Boot validation at the shim level, but most tasks require a previously set password to be entered to confirm that the user at console is indeed the person who requested changes. Such passwords only survive across a single run of shim / MokManager; and are cleared as soon as the process is completed or cancelled. Once key management is completed, the system is rebooted and does not simply continue with booting, since the key management changes may be required to successfully complete the boot.
Once the system continues booting to GRUB; the GRUB process loads any required configuration (usually loading configuration from the ESP (EFI System Partition), pointing to another configuration file on the root or boot partition), which will point it to the kernel image to load.
EFI applications up to this point having full access to the system firmware, including access to changing trusted firmware variables, the kernel to load must also be validated against the trust database. Official Ubuntu kernels being signed by the Canonical UEFI key, they are successfully validated, and control is handed over to the kernel. Initrd images are not validated.
Up to this point, any failure to validate an image to load is met with a critical error which stops the boot process. The system will not continue booting, and may automatically reboot after a period of time given that other BootEntry variables may contain boot paths that are valid and trusted.
Once loaded, validated kernels will disable the firmware’s Boot Services, thus dropping privileges and effectively switching to user mode; where access to trusted variables is limited to read-only. Given the broad permissions afforded to kernel modules, any module not built into the kernel will also need to be validated upon loading. Modules built and shipped by Canonical with the official kernels are signed by the Canonical UEFI key and as such, are trusted. Custom-built modules will require the user to take the necessary steps to sign the modules before they loading them is allowed by the kernel. This can be achieved by using the ‘kmodsign’ command [see
Unsigned modules are simply refused by the kernel. Any attempt to insert them with insmod or modprobe will fail with an error message.
Given that many users require third-party modules for their systems to work properly or for some devices to function; and that these third-party modules require building locally on the system to be fitted to the running kernel, Ubuntu provides tooling to automate and simplify the signing process.
How can I do non-automated signing of drivers?
Some projects may require the use of custom kernel drivers that are not set up in such a way as to work with DKMS. In these cases, people should make use of the tools included in the shim-signed package: the update-secureboot-policy script is available to generate a new MOK (if no DKMS-built modules have triggered generating one already).
Use the following command to enroll an existing key into shim:
If no MOK exists, the script will exit with a message to that effect. If the key is already enrolled, the script will exit, doing nothing. If the key exists but it not shown to be enrolled, the user will be prompted for a password to use after reboot, so that the key can be enrolled.
One can generate a new MOK using the following command:
And then enroll the newly-generated key into shim with the previously-mentioned command for that task.
Kernel modules can then be signed with the kmodsign command (see UEFI/SecureBoot/Signing) as part of their build process.
Security implications in Machine-Owner Key management
The MOK generated at installation time or on upgrade is machine-specific, and only allowed by the kernel or shim to sign kernel modules, by use of a specific KeyUsage OID (1.3.6.1.4.1.2312.16.1.2) denoting the limitations of the MOK.
Recent shim versions include logic to follow the limitations of module-signing-only keys. These keys will be allowed to be enrolled in the firmware in shim’s trust database, but will be ignored when shim or GRUB validate images to load in firmware. Shim’s verify() function will only successfully validate images signed by keys that do not include the «Module-signing only» (1.3.6.1.4.1.2312.16.1.2) KeyUsage OID. The Ubuntu kernels use the global trust database (which includes both shim’s and the firmware’s) and will accept any of the included keys as signing keys when loading kernel modules.
Given the limitations imposed on the automatically generated MOK and the fact that users with superuser access to the system and access to the system console to enter the password required when enrolling keys already have high-level access to the system; the generated MOK key is kept on the filesystem as regular files owned by root with read-only permissions. This is deemed sufficient to limit access to the MOK for signing by malicious users or scripts, especially given that no MOK exists on the system unless it requires third-party drivers. This limits the possibility of compromise from the misuse of a generated MOK key to signing a malicious kernel module. This is equivalent to compromise of the userland applications which would already be possible with superuser access to the system, and securing this is out of the scope of UEFI Secure Boot.
Previous systems may have had Secure Boot validation disabled in shim. As part of the upgrade process, these systems will be migrated to re-enabling Secure Boot validation in shim and enrolling a new MOK key when applicable.
MOK generation and signing process
The key generation and signing process is slightly different based on whether we are dealing with a brand new installation or an upgrade of system previously running Ubuntu; these two cases are clearly marked below.
In all cases, if the system is not booting in UEFI mode, no special kernel module signing steps or key generation will happen.
If Secure Boot is disabled, MOK generation and enrollment still happens, as the user may later enable Secure Boot. They system should work properly if that is the case.
The user installs Ubuntu on a new system
The user steps through the installer. Early on, when preparing to install and only if the system requires third-party modules to work, the user is prompted for a system password that is clearly marked as being required after the install is complete, and while the system is being installed, a new MOK is automatically generated without further user interaction.
Third-party drivers or kernel modules required by the system will be automatically built when the package is installed, and the build process includes a signing step. The signing step automatically uses the MOK generated earlier to sign the module, such that it can be immediately loaded once the system is rebooted and the MOK is included in the system’s trust database.
Once the installation is complete and the system is restarted, at first boot the user is presented with the MokManager program (part of the installed shim loader), as a set of text-mode panels that all the user to enroll the generated MOK. The user selects «Enroll MOK», is shown a fingerprint of the certificate to enroll, and is prompted to confirm the enrollment. Once confirmed, the new MOK will be entered in firmware and the user will be asked to reboot the system.
When the system reboots, third-party drivers signed by the MOK just enrolled will be loaded as necessary.
The user upgrades an UEFI-enabled Ubuntu system to a new release where the system requires third-party drivers
On upgrade, the shim and shim-signed packages are upgraded. The shim-signed package’s post-install tasks proceeds to generate a new MOK, and prompts the user for a password that is clearly mentioned as being required once the upgrade process is completed and the system rebooted.
During the upgrade, the kernel packages and third-party modules are upgraded. Third-party modules are rebuilt for the new kernels and their post-build process proceeds to automatically sign them with the MOK.
After upgrade, the user is recommended to reboot their system.
On reboot, the user is presented with the MokManager program (part of the installed shim loader), as a set of text-mode panels that all the user to enroll the generated MOK. The user selects «Enroll MOK», is shown a fingerprint of the certificate to enroll, and is prompted to confirm the enrollment. The user is also presented with a prompt to re-enable Secure Boot validation (in the case it was found to be disabled); and MokManager again requires confirmation from the user. Once all steps are confirmed, shim validation is re-enabled, the new MOK will be entered in firmware and the user will be asked to reboot the system.
When the system reboots, third-party drivers signed by the MOK just enrolled will be loaded as necessary.
In all cases, once the system is running with UEFI Secure Boot enabled and a recent version of shim; the installation of any new DKMS module (third-party driver) will proceed to sign the built module with the MOK. This will happen without user interaction if a valid MOK key exists on the system and appears to already be enrolled.
If no MOK exists or the existing MOK is not enrolled, a new key will automatically created just before signing and the user will be prompted to enroll the key by providing a password which will be required upon reboot.
UEFI/SecureBoot (последним исправлял пользователь dannf 2020-04-08 14:07:55)
Используем 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 на каждый загрузчик.