Полное шифрование диска в Linux без initramfs

Существуют ли какие-либо схемы шифрования на полном диске, которые можно выполнить без initramfs, а получить ключ шифрования из cmdline ядра? Я знаю, это звучит небезопасно, поскольку злоумышленник может просто прочитать файлы загрузчика; но из-за процесса загрузки этого устройства, я должен вручную вводить cmdline при каждой загрузке.

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

Нет.

Ну, обычно FDE должен быть на аппаратном (а не на Linux), откуда берется kernel. Предполагая, что вы решили это (возможно, связано с вашим предложением менее типичного процесса загрузки) …

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

(Технически есть rootdelay= опция rootdelay= . Но нет загрузочной опции для монтирования двух rootfs друг на друга, и нет загрузочной опции для расшифровки блочного устройства с любой схемой)

Обычно /proc/cmdline может быть прочитан любым процессом в пользовательском пространстве, поэтому Linux не рекомендует помещать в него секретные ключи. Примирить такую ​​идею с потребностями безопасности, подразумеваемыми FDE, сложно, но, возможно, есть некоторые надуманные обстоятельства …

Это звучит почти так же, как если вы хотите передать ядру большой двоичный код пользовательского пространства, который может создать стек хранения любым способом, который вы выберете. Даже способы, которые разработчики ядра не одобрили бы :-). Вы можете передать BLOB-объект во время загрузки. Или вы можете иметь возможность встроить его в kernel. Мы могли бы назвать это начальными ramfs или initramfs для краткости. Хорошие новости! Кто-то уже реализовал эту функцию ядра для вас.

Вопрос не говорит, почему это слово из 9 букв не должно произноситься. Поскольку вы делаете пользовательскую компиляцию, вы всегда можете исправить любое имя, которое вам нравится :-P.

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

Он не должен быть таким большим, как дистрибутив initramfs. Например, быстрый поиск нашел это как правдоподобную отправную точку:

https://gist.github.com/packz/4077532

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