With Ubuntu or really any Linux distro have people successfully used LUKS and specifically full disk encryption ? Any specific issues to be aware of going into the install?
Just did that on arch with no issues. Unencrypted boot partion + encrypted root. Btrfs within the luks container and add unlock command to grub kernel parameter. It works just as described on the arch wiki here
There are also many other options explained.
No problems with encryption, just a heads up that you could cut the performance of your NVMe up to 50% while you are using encryption.
Just something to think about
Of course, there is no encryption without penalty. Also make sure you pass allow_discards in your kernel parameter to trim your ssd.
No issues with full disk encryption using LUKS on Arch. unencrypted
/boot, encrypted root, encrypted swap.
No issues! I followed a mash-up of this Windows/Ubuntu installation guide for the Framework and this guide to installing (Windows and) Ubuntu with LUKS encryption and LVM to set up a Windows install (with Windows EFI System Partition and the regular Windows partitions) and an Xubuntu install (with its own EFI partition which ends up as the default boot partition and can boot Xubuntu or Windows via GRUB, an unencrypted /boot partition, and a LUKS partition with root, swap, and home LVM logical volumes in it).
[Boring details follow, in case useful for anybody — but the guides linked above explain this more clearly.]
I first did the Windows install, leaving lots of space for Linux. Then I booted into the Xubuntu live session (“try xubuntu” from the installer media) and manually added the Linux partitions (second EFI, /boot, and LUKS-encrypted partition), made the decrypted equivalent of the LUKS partition an LVM physical volume, added it to a volume group, and and created the root, swap, and home partitions in that volume group. Then I launched the Xubuntu installer from the live session and did the install. Before rebooting, I had to chroot into the freshly installed system and add an /etc/crypttab to allow decrypting the LUKS partition at boot and rebuild the initrds. Somewhat to my surprise, everything worked after rebooting. And I can boot into Win 10 Pro or Xubuntu at will. (Haven’t yet tried starting one as a VM under the other, but I feel confident that will work.)
No issues with LUKS here. Created an unencrypted ESP (EFI System Partition), unencrypted
/boot, and encrypted container with 3 LVM volumes (Root, Home, Swap) inside it. On boot, I get a prompt to unlock my LUKS volume which then exposes the different LVM volumes. Also, because of this setup, hibernate works quite well (unlike the case where swap is encrypted by a random key generated at startup).
Just came back to say I finished my install. (twice) once with LTS version before realizing wifi issues. Then went with Ubuntu 21.04 and actually trying ZFS. Both installed no problem and LUKS appears properly configured.
I’ve benchmarked Manjaro with and without full disk encryption (fresh installs in each case) using Geekbench 5. I haven’t gone through the individual numbers, but overall there doesn’t seem to be any difference in performance between encrypted and unencrypted SSD. All tests were running off of battery (no power cable connected). Quick boot is enabled. Quiet boot is disabled.
Here are my benchmark results:
The main drawbacks of full disk encryption appear to be:
- Startup time increased by about +30s
- If you lose your passphrase, there is no recovery
I enabled auto-login, because I don’t want to have to type in my passphrase and then type in my login password as well. I set up a swap partition for hibernation, but I haven’t attempted to get that working yet.
I did the “easy” full disk encryption install on Manjaro. I didn’t partition the disk myself. I just let Manjaro take care of it.
Start up times:
w/o full disk encryption:
20s to login prompt
w/ full disk encryption and login bypass disabled:
8s to encryption passphrase prompt
43s to login
w/ full disk encryption and login bypass enabled:
8s to encryption passphrase prompt
43s auto-login to desktop
If I plug in the power cable, there is essentially no difference in start-up time with full disk encryption (vs. running on battery power).
Hmm, it shouldn’t take that much longer to get to the login screen. Maybe a few seconds longer or so, but not 23s.
I don’t know what might contribute to a long startup time. I have a 2TB disk. This start-up time is acceptable for me.
I occasionally mis-type my passphrase, which drops me to a grub rescue prompt. I just power-cycle and enter the passphrase again.
My laptop is quite snappy, so I’ll stick with the full disk encryption.
Yeah, this is why I use an unencrypted
/boot partition. That way, the OS handles the decryption (not GRUB) and lets you try multiple times (it also supports LUKS2, which is way better in so many ways).
I see. Thanks for the suggestion. I will try that. Seems like that should allow it to boot up much faster.
To give you some details, this is what my current partition layout looks like on my desktop:
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS sda 8:0 0 1.8T 0 disk └─sda1 8:1 0 1.8T 0 part └─sda1_crypt 254:3 0 1.8T 0 crypt └─Crypto--Data-Home 254:4 0 1.8T 0 lvm /home nvme0n1 259:0 0 465.8G 0 disk ├─nvme0n1p1 259:1 0 476M 0 part /boot/efi ├─nvme0n1p2 259:2 0 477M 0 part /boot └─nvme0n1p3 259:3 0 464.8G 0 part └─nvme0n1p3_crypt 254:0 0 464.8G 0 crypt ├─Crypto-Root 254:1 0 425.6G 0 lvm / └─Crypto-Swap 254:2 0 29.8G 0 lvm [SWAP]
nvme0n1p1 here is the ESP (EFI System Partition).
nvme0n1p2 is my unencrypted boot partition.
nvme0n1p3 is just a giant encrypted block. Inside
nvme0n1p3_crypt (the name for the mounted encrypted volume), I have a LVM setup with two volumes:
sda1 is a giant encrypted block. Inside
sda1_crypt (the name for the mounted encrypted volume), I have a LVM setup with only one volume:
The only difference with my Framework is that
/home gets put in the same volume group as
swap (since there’s only one storage medium on there). So basically, you’d see
Crypto-Home in addition to
Crypto-Swap. Everything else (crucially, the setup of
/boot) remains the same.
Thanks! It turns out that my /boot/efi is not encrypted. So, I don’t know why it’s taking so long to boot up.
Edit: I ran the following command, and it took 3 seconds.
sudo cryptsetup -v luksOpen --test-passphrase /dev/nvme0n1p2
Edit 2: Oh, here is a video on how to set this up with /boot unencrypted. Now I notice above that you have both /boot and /boot/efi. So, I need to add that unencrypted /boot partition. Right now it’s under the ‘/’ mountpoint.
Are your kernels stored in
/boot/efi? Or in
/boot? Because if they’re stored in
/boot and you don’t have a separate (unencrypted)
/boot partition, you’ll run into slow boots since GRUB has to handle the decryption.
Exactly! Sometimes people will setup their ESP as their
/boot partition, but I don’t like to do that since that partition has to be VFAT, whereas I would prefer my
/boot partition to be a regular (read: ext4) partition. Hence I keep separate
It was a little tricky, but if anyone installing Manjaro wants a quicker boot experience, I’ve put some instructions on how to do that over here:
In short, with the calamares installer (which is what Manjaro uses) you would need to partition manually with an unencrypted
/boot/ partition. When you specify that partition, it seems that you must supply a trailing
/. Additionally, you will need to update grub, per the instructions which I linked to, after booting into the newly installed system in order to avoid being prompted an extra time for the encryption passphrase (which it doesn’t need in order to open the boot partition).
So, the next problem is that I don’t know how to get the encrypted swap partition working, let alone get it working for hibernation. By default, the swap partition is not being used, and my attempts to turn it on have not been successful.
The desired setup would have the root partition and swap partition in the same encrypted container, as Chiraag_Nataraj indicated above, in order to avoid having to enter the encryption passphrase twice. However, the path of least resistance for me may be to use an encrypted swap file on the root partition.
@Paul_Stone Here’s how I setup partitions during install (I installed Debian, but the partitioner should be fairly similar if you do the manual partitions):
- Delete existing partition table. Yes, that includes the EFI partition if you have one, since you’ll recreate it anyway.
- Create a new partition. Set the type to EFI and the size to whatever you want (looking at my current desktop, I set it to about 500MiB).
- Create a new partition. Set the type to ext4, the mountpoint to
/boot, and the size to whatever you want (again, I use about 500MiB on my desktop).
- Create a new partition. Set the type to crypt and set it to use the rest of the disk.
- In Debian, there’s another sub-menu at the partitioner to setup encrypted volumes, and I enter that and setup my passphrase and such at this step. I don’t know if Calamares does something similar or if it comes up at the previous step when you set the type of the partition to crypt. Either way, I will assume that at this point, you have created an encrypted container which takes up the rest of the disk (after your EFI partition and
- Now, at the partitioner’s main screen, I see a new ‘disk’, which is the encrypted volume I setup and has been mounted to expose the internal space.
- Create a new partition in the encrypted volume and let it take up the entire space. Set the type to LVM.
- Now, in Debian, there’s another submenu to setup LVM, so I enter that.
- Here, I can create a volume group (I usually name it Crypto) and several logical volumes inside of that volume crypto. This is where I create Root, Home, and Swap.
- Once I exit the LVM setup, I see that three new ‘disks’ have appeared, each one corresponding to a logical volume I created and unformatted at the moment.
- At this point, I can go to each of those and setup the appropriate partitions (
- Once the install completes, everything should “Just Work”.
The one thing I don’t know is if Calamares uses a partitioner other than
partman (which is what Debian uses). If it does, then the way the options are exposed to you (especially for crypto and LVM) may be different.