Про полнодисковое шифрование #
FDE средствами #
LuksНа ровном месте проявилась проблема, что идентификаторы разделов (partitions) теряются в определённых обстоятельствах. Потому система не может загрузиться, из-за чего в опции
rd.luks.data приходится использовать
/dev/disk/by-id/... вместо UUID'а раздела на диске.
Т.е. идентификатор шифрованного LUKS-раздела затирается в каких-то обстоятельствах и отдельных случаях, тем самым является совершенно ненадёжным способом указания на раздел диска.
Например, это затирание было замечено после того как выполнялось выставление флагов allow-discards, no_read_workqueue и no_write_workqueue через:
cryptsetup open --type luks2 --persistent --allow-discards --perf-no_read_workqueue --perf-no_write_workqueue ...Соответственно, для `systemd-boot` загрузчика в файле /boot/loader/etries/your-system-100.500.conf приходится указывать нечто сродни:
options rd.luks.data=7f2df3a2-3c68-492e-bbd6-1ccf956379c0=/dev/disk/by-id/nvme-VENDOR_MODEL_SERIAL_ID_-partN
options rd.luks.name=7f2df3a2-3c68-492e-bbd6-1ccf956379c0=crypto_dev_name
... или ...
options rd.luks.data=2b507209-fcf1-4aae-a55a-1ba4e908cc8b=/dev/disk/by-id/ata-VENDOR_MODEL_SERIAL_ID_-partN
Где:
- partN — это part1 или part2... part3 и т.д. номер разделов.
- Используемые UUID'ы это из Luks-заголовка, т.е видимые через
cryptsetup luksDump и отсутствующие в выдаче:
lsblk -f - Идентификаторы разделов конкретного диска ...-VENDOR_MODEL_SERIAL_ID_-partN можно наблюдать через:
ls /dev/disk/by-id/
Тоже самое касается и /etc/cryptsetup.initramfs, если таковой используется.
Почему #
systemd-boot?
Использование #
GRUB весьма
неразумно при полнодисковом шифровании, так же использовать GRUB затруднительно, когда при старте надо открывать несколько шифрованных разделов.
Например, один из разделов на диске может быть swap, в который сохраняется система при hibernate. Да swap может быть и файлом на основном разделе, но далеко не всех такое устраивает и не все файловые системы это поддерживают.
#
lang_ru #
linux #
LUKS
