5 ms·

I have a full disk encryption setup for my Ubuntu. It uses LVM, LUKS, and cryptosetup in GRUB. The problem is that it takes forever to boot (5 min, not kidding

by 21 8y ago

I have a full disk encryption setup for my Ubuntu. It uses LVM, LUKS, and cryptosetup in GRUB. The problem is that it takes forever to boot (5 min, not kidding). Apparently the whole boot partition is decrypted to a RAM disk or something.

mjevans 8y ago
This depends heavily on your security model... Are you trying to use just a literal 'usb key' as a fob for booting the computer? Decrypting the LUKS key will take some time, but you can ship the key for decrypting that in the initramfs that you'd store with the kernel on the USB drive.
- deleted 8y ago
  [deleted]
lgunsch 8y ago
I have my whole disk encrypted, including swap, and use LVM with BTRFS on top. My key is included in the initramfs. After I type my password in the Grub prompt, it only takes about 60 to 90 seconds to do a full boot. Although, the disk is a SSD. I'm sure if I didn't have a SSD disk, the boot process would take a very long time.
- scintill76 8y ago
  I've similarly included my key in the initramfs, until I noticed the initramfs file in /boot is world-readable. (On Linux Mint.) I'm a bit over-paranoid maybe, but I don't want a compromise of my user account turning into compromising my keys. Have you had that issue, and fixed it cleanly? (I could just chmod, but I don't want to have to remember.) For now, I just enter my password twice -- once for GRUB to load Linux, then again in Linux's early boot. I've been tempted to implement some way for GRUB to pass the key to Linux in RAM, avoiding the need for a key file.
  - lgunsch 8y ago
    My initramfs is only readable by root (0600). The key is also in a file only readable by root (0600). The key file is added into the initramfs image when it's built. edit: I'm on Arch Linux
    - zeth___ 8y ago
      What's to stop someone with a live cd from reading it by mounting the file system?
      - lgunsch 8y ago
        /boot is also fully encrypted on my system - which includes the initramfs, the backup initramfs, kernel, grub config, etc. /boot/efi is not encrypted, but only has the EFI modules. The first stage of Grub (not sure one terminology here) knows about LUKS encrypted partitions and how to decrypt them. Only version 1 of the header though - found that out the hard way.
        mmirate 8y ago
        Then - since you aren't claiming to be Mike Cardwell - how do you know that your unencrypted LUKS drivers and EFI modules haven't been tampered-with?
        CBLT 8y ago
        Not the person you're asking, but see this reddit comment[0] >If you are using a proper private secure boot setup (not the Microsoft keys, signing keys not accessible to an attacker that remotely compromises your system), you trust that your motherboard implements it correctly, you can safely assume nobody is physically tampering with your motherboard and you're using a variant of GRUB that fully implements secure boot, ESP access gives your attacker nothing. They can't change anything there without breaking the system. [0] https://www.reddit.com/r/linux/comments/7n92ip/linux_boot_partition_encryption/ds0epw3/ https://www.reddit.com/r/linux/comments/7n92ip/linux_boot_pa...
- CBLT 8y ago
  > 60 to 90 seconds That seems pretty long, what's your setup? I noticed mine taking much longer than it should, and the reason seemed to be a lot of useless PKDF time. For every disk I had to decrypt, my system went through the LUKS table and tried the keyfile in order. By putting the keyfile entry first in the table and configuring it to minimum PKDF time (just for the keyfile, still millions of sha512 for passwords) my disks all decrypted in a couple seconds.
  - lgunsch 8y ago
    I probably over estimated a bit, and I only reboot about once a week or so. I only have the one disk to decrypt, and one key. When I was setting it all up I did run cryptsetup benchmark to choose the best hashing algorithm for my architecture. It ended up to be aes-xts sha256. Has enough iterations for about 2.5 seconds.
- Rjevski 8y ago
  If you’re letting GRUB handle the disk decryption then that’s part of your problem. The key derivation function in GRUB is much slower than in Linux. If possible, switch to an unencrypted boot partition (and rely on Secure Boot to ensure integrity of GRUB and kernels), and only decrypt the encrypted partitions within Linux (more specifically in the initramfs).
kzrdude 8y ago
I just boot using full root mount encryption (but the /boot & initrd is not encrypted). So it's lame, but it boots super fast (10 seconds including password typing), the main waiting time is to type in the password.
CJefferson 8y ago
There is also a number of problems in Ubuntu installs -- I was having a similar problem, this fixed it for me: https://askubuntu.com/questions/1029050/long-boot-times-on-18-04 https://askubuntu.com/questions/1029050/long-boot-times-on-1...
sydney6 8y ago
You might perhaps want to try another hashing algorithm for your /boot FS. https://unix.stackexchange.com/questions/369414/grub-takes-too-long-to-unlock-the-encrypted-boot-partition https://unix.stackexchange.com/questions/369414/grub-takes-t...
newnewpdro 8y ago
This is not normal.
tscs37 8y ago
I use LVM and LUKS too. While I haven't encrypted /boot (due to using UEFI) I do have full disk encryption on the remaining disks. The longest delay is mounting the spinning disks but overall after I enter the password boot takes less than 30 seconds... I would recommend to check the output of the following commands: systemd-analye systemd-analyze critical-chain These will output the boot times (firmware, bootloader, kernel, initrd, userspace) and the service chain that took the longest during boot.

by 21 8y ago

mjevans 8y ago

This depends heavily on your security model... Are you trying to use just a literal 'usb key' as a fob for booting the computer? Decrypting the LUKS key will take some time, but you can ship the key for decrypting that in the initramfs that you'd store with the kernel on the USB drive.

deleted 8y ago
[deleted]

lgunsch 8y ago

I have my whole disk encrypted, including swap, and use LVM with BTRFS on top. My key is included in the initramfs. After I type my password in the Grub prompt, it only takes about 60 to 90 seconds to do a full boot. Although, the disk is a SSD. I'm sure if I didn't have a SSD disk, the boot process would take a very long time.

scintill76 8y ago
I've similarly included my key in the initramfs, until I noticed the initramfs file in /boot is world-readable. (On Linux Mint.) I'm a bit over-paranoid maybe, but I don't want a compromise of my user account turning into compromising my keys. Have you had that issue, and fixed it cleanly? (I could just chmod, but I don't want to have to remember.) For now, I just enter my password twice -- once for GRUB to load Linux, then again in Linux's early boot. I've been tempted to implement some way for GRUB to pass the key to Linux in RAM, avoiding the need for a key file.
- lgunsch 8y ago
  My initramfs is only readable by root (0600). The key is also in a file only readable by root (0600). The key file is added into the initramfs image when it's built. edit: I'm on Arch Linux
  - zeth___ 8y ago
    What's to stop someone with a live cd from reading it by mounting the file system?
    - lgunsch 8y ago
      /boot is also fully encrypted on my system - which includes the initramfs, the backup initramfs, kernel, grub config, etc. /boot/efi is not encrypted, but only has the EFI modules. The first stage of Grub (not sure one terminology here) knows about LUKS encrypted partitions and how to decrypt them. Only version 1 of the header though - found that out the hard way.
      - mmirate 8y ago
        Then - since you aren't claiming to be Mike Cardwell - how do you know that your unencrypted LUKS drivers and EFI modules haven't been tampered-with?
        CBLT 8y ago
        Not the person you're asking, but see this reddit comment[0] >If you are using a proper private secure boot setup (not the Microsoft keys, signing keys not accessible to an attacker that remotely compromises your system), you trust that your motherboard implements it correctly, you can safely assume nobody is physically tampering with your motherboard and you're using a variant of GRUB that fully implements secure boot, ESP access gives your attacker nothing. They can't change anything there without breaking the system. [0] https://www.reddit.com/r/linux/comments/7n92ip/linux_boot_partition_encryption/ds0epw3/ https://www.reddit.com/r/linux/comments/7n92ip/linux_boot_pa...
CBLT 8y ago
> 60 to 90 seconds That seems pretty long, what's your setup? I noticed mine taking much longer than it should, and the reason seemed to be a lot of useless PKDF time. For every disk I had to decrypt, my system went through the LUKS table and tried the keyfile in order. By putting the keyfile entry first in the table and configuring it to minimum PKDF time (just for the keyfile, still millions of sha512 for passwords) my disks all decrypted in a couple seconds.
- lgunsch 8y ago
  I probably over estimated a bit, and I only reboot about once a week or so. I only have the one disk to decrypt, and one key. When I was setting it all up I did run cryptsetup benchmark to choose the best hashing algorithm for my architecture. It ended up to be aes-xts sha256. Has enough iterations for about 2.5 seconds.
Rjevski 8y ago
If you’re letting GRUB handle the disk decryption then that’s part of your problem. The key derivation function in GRUB is much slower than in Linux. If possible, switch to an unencrypted boot partition (and rely on Secure Boot to ensure integrity of GRUB and kernels), and only decrypt the encrypted partitions within Linux (more specifically in the initramfs).

kzrdude 8y ago

I just boot using full root mount encryption (but the /boot & initrd is not encrypted). So it's lame, but it boots super fast (10 seconds including password typing), the main waiting time is to type in the password.

CJefferson 8y ago

There is also a number of problems in Ubuntu installs -- I was having a similar problem, this fixed it for me: https://askubuntu.com/questions/1029050/long-boot-times-on-18-04 https://askubuntu.com/questions/1029050/long-boot-times-on-1...

sydney6 8y ago

You might perhaps want to try another hashing algorithm for your /boot FS. https://unix.stackexchange.com/questions/369414/grub-takes-too-long-to-unlock-the-encrypted-boot-partition https://unix.stackexchange.com/questions/369414/grub-takes-t...

newnewpdro 8y ago

This is not normal.

tscs37 8y ago

I use LVM and LUKS too. While I haven't encrypted /boot (due to using UEFI) I do have full disk encryption on the remaining disks. The longest delay is mounting the spinning disks but overall after I enter the password boot takes less than 30 seconds... I would recommend to check the output of the following commands: systemd-analye systemd-analyze critical-chain These will output the boot times (firmware, bootloader, kernel, initrd, userspace) and the service chain that took the longest during boot.