Uefi and full disk encryption with lvm on luks
Yeah, i know it's a pretty late answer but, better late than never...
I don't know if Debian has the tools to do it, but using Arch Linux you can create a disk layout like this:
- EFI partition(mounted
/boot/efi
) with grub EFI bootloader, formated fat32 EFI type partitionEF00
. Could be your/dev/sda1
. This partition will only hold grub stub, to ask password to mount your boot partition. - boot partition(mounted
/boot
) that is a luks crypto device. After crypto unlocking this partition, you can format it using any filesystem that grub supports to but(ext4 for example). This will be your/dev/sda2
- Crypto device that will store all remaining partitions as logical volumes. Crypto device, with LVM and its logical volumes(3 layers). This will be your
/dev/sda3
.- Here, you can create as many logical volumes as you want/need. The key that unlocks this partition will be used to access data on all it's logical volumes.
Borrowing from Arch Wiki, this is how your disk layout will looks like:
+---------------+----------------+----------------+----------------+----------------+
|ESP partition: |Boot partition: |Volume 1: |Volume 2: |Volume 3: |
| | | | | |
|/boot/efi |/boot |root |swap |home |
| | | | | |
| | |/dev/store/root |/dev/store/swap |/dev/store/home |
|/dev/sdaX |/dev/sdaY +----------------+----------------+----------------+
|unencrypted |LUKS encrypted |/dev/sdaZ encrypted using LVM on LUKS |
+---------------+----------------+--------------------------------------------------+
Caveats:
- Grub will ask for a password to unlock
/boot
, initial ram disk will ask for a password AGAIN(cause for him,/boot
is locked), and probably while mounting yourroot
partition this will happen once more. The trick here is to use a master key inside your/boot
(and maybe inside your initrd with theFILES=
option ofmkinitcpio
and add it withluksAddKey
. Your boot partition is encrypted so, there is no need to be worried cause the key is inside an encrypted partition.chmod 000 keyfile.bin
is your friend. - Add
encrypt lvm2
tomkinitcpio
hooks. - If for some reason your system is not able to use the key, a password will be asked again.
- You will still be vulnerable to Evil Maid attacks that explore Cold Boot failures. The best you can do here is:
- Enable Secure Boot.
- Sign your Grub EFI.
- Revoke Microsoft CA on your Motherbord(you know, can't trust anyone).
- Remember to Sign you grub efi whenever you have a
grub-efi
package update.
Further Reading:
After some research about the need of keeping boot partition outside lvm(as far as i know, grub-pc/bios had lvm
and luks
modules) i found this guy on Arch Forums confirming that there is no need to keep /boot
on a spare crypto partition.
You can install grub on your ESP
, and also tell it to read the configuration files from esp like this:
# grub-install --target=x86_64-efi --efi-directory=esp --bootloader-id=grub --boot-directory=esp
after that, regenerate conf:
# grub-mkconfig -o esp/grub/grub.cfg
And, it seems that grub
is the only bootloader that have support to boot lvm+crypto without a separated /boot partition.
Related videos on Youtube
Egidio Docile
Updated on September 18, 2022Comments
-
Egidio Docile over 1 year
I have an ASUS machine on which I can choose between the old BIOS and the new UEFI. I've always used the old BIOS system, running a full encrypted Debian with the following configuration:
An unencrypted boot partition mounted at
/boot
All the rest of the space encrypted with LUKS, and with all LVM logical volumes (
/
, swap,/home
) on it.
Everything works well and with no problems. But I was wandering if I want to make a new install from scratch (I don't want to convert stuff) using UEFI, and I have to create the FAT32 EFI partition mounted at
/boot/efi
, do I still need the unencrypted/boot
partition, or just the EFI partition and all the rest encrypted?In other words, which configuration would be right?
/boot/efi
/boot
- Encrypted LUKS volume
or
/boot/efi
- Encrypted LUKS volume?
-
naught101 about 7 yearsWhat's the point of the /boot partition? Why not just have grub unlock / directly, and install boot files to <root>/boot?
-
Admin about 7 yearsit looks like you didn't read the "Further Reading" section, do you? The point of a spare
/boot
was because some time ago grub could not open natively luks encrypted drives. -
ljrk almost 5 yearsDoes that really make sense to have the grub config unencrypted on the ESP? Wouldn't it make more sense to have the esp only contain grub which is just configured to prompt for a decryption passphrase for /boot that actually contains the configurations and the kernel?