Manual Full System Encryption has been updated and simplified

[Paddy Landau]

I apologize, I stand corrected…

No problem. Thanks to your previous comments, I discovered that VirtualBox allows me to create a NVMe controller, which let me see how it worked. So it was all good — I learned something (always good to do); and I made the script both more robust and more flexible.

… which could enable us to have the boot unencrypted but still signed and checked…

That's not necessary, because the full-system encryption includes /boot within LVM, which is in turn within LUKS. It all works. The important point is the next one that you make:

I was really hoping not to have to read shim's and grub's source code and hoping to understand how to debug the key validation, and why GRUB_CRYPTED_DISK=y loads cryptomount module only with secureboot disabled. No eta on that tough.

That's the big one. We need to have proper signing on the EFI System Partition, because that's the only vector for malware on a locked machine. Unfortunately, it is way beyond my level of competence to even comment on how.

I refer you to the bug's comment #25 by Jonathan Polom, who explains a bit more about the signing flaw. I'd love to raise a bug report for this shortcoming, but I have insufficient knowledge to even begin to frame the report.

[flyffies]

Hi,

I tried to install Ubuntu with the tutorial on a portable usb drive I could use on my travels, so I am not bound to any hardware other than the drive.

I ran into the issue that on boot the drive definitions could change, and if they do the system is unable to find the excrypted partition and decrypt it.

Has anyone a solution to this or could think of any? What I found and tried didn't work sadly...

Big thank you in advance

[Paddy Landau]

I tried to install Ubuntu with the tutorial on a portable usb drive I could use on my travels, so I am not bound to any hardware other than the drive.

The first thing to check is that you used the portable drive, not the internal drive, as your bootloader. So, after your installation, what you should have is:

• Your internal hard drive, which is probably /dev/sda, containing its ESP (EFI System Partition) and its own bootloader.
• Your external portable USB drive, probably /dev/sdb, which contains its own ESP, and its own bootloader.

So, you should have a situation where each drive is completely independent of each other. The internal hard drive's setup should be blissfully unaware of the external drive's ESP and system. The external drive will know about the internal drive, but you can safely ignore that — the important thing is that it has its own ESP and its own bootloader.

I hope that I've explained myself clearly.

I emphasise that I actually haven't tested this, because my hardware is a bit old and clunky, but if you still have problems with this, I'll test it myself anyway.

Let us know if you've already done this, or if not, what happens if you try it. It "should" work because the drive access is via the UUID rather than the symbolic /dev/sdb; the former won't change, but the latter might.

This situation didn't occur to me previously, so I should add this into the documentation. Let's wait until you get it working, though.

[flyffies]

Hi,

thanks for the response.

Yea, I installed the bootloader onto the external drive (in my case /dev/sdc, the install usb-stick took /dev/sdb, internal /dev/sda) it worked on the first reboot, where I didn't change anything.
On the second reboot I remove the usb-stick and still grub could not find the correct partition to decrypt. I could choose ubuntu from its menu, but it wouldn't ask for the password...

I will do a clean install later and try it again, maybe I messed up somewhere else.

[Paddy Landau]

I will do a clean install later and try it again, maybe I messed up somewhere else.

Yes, that sounds like a good idea.

I felt a little uncertain what exactly you were saying about the first reboot and the second reboot, sorry.

Assuming that your reinstallation again puts your external USB drive on /dev/sdc: Take great care, when you reinstall, to use no drives or partitions other than on /dev/sdc. There are two places where you note the bootloader: one, in the script in the terminal, and two, in the Installer. Please mark them both as /dev/sdc.

If the reinstallation still doesn't work, let us know and I'll run a test.

[flyffies]

So... I tested and made sure to install everything on the correct disk, my external USB Disk (Was sdb this time).

I changed the refreshgrub script to point to the correct disk by using the /dev/disk/by-id/ link. It started, I updated the system and rebootet. And sure enought, it booted, I put in my system password and Ubuntu loaded.

After trying to install steam (and failing) and the AMD Pro drivers I tired to reboot and was unable to boot.

I could select my drive in the bios boot menu, but it didn't say ubuntu anymore as before, it was just the Drive name.
I selected it and was only greetet by 3 lines of text:

Press F1 key to retry boot.
Press F2 key to reboot into setup.
Press F5 key to run onboard diagnostics.

I wasn't able to boot anymore. I had variations where I could see the grub menu and select ubuntu, but after entering the password it would complain, about not being able to find the partion with the specified UUID.

I really appreciate you helping me. Thanks a lot!

[Paddy Landau]

Hm, all right. That is not what I expected, but then, as I explained in the instructions, I'm not exactly a technical boffin (almost everything that I did was merely putting together what other people discovered or told me).

I'm going to test this — I might not have time until next week — and I'll get back to you in this thread.

[em93jgm]

Hi Paddy,

Thank you for the hard work!

I have solved one issue with the install that was due to my specific environment: I had a working dual boot Windows + Ubuntu 18.04 but wanted to encrypt Ubuntu. To make a back up, I cloned all my working partitions to a second drive and then followed your instructions, leaving my EFS partition alone with the windows bootloader and old ubuntu grub. When it came to booting, grub could not find the grub.cfg because it now searches for a partition UUID in EFI/ubuntu/grub.cfg. I believe grub found my cloned partition which was obviously out of date and did not have the linked grub.cfg. When I changed the clone's UUID, the system now booted ok.

My second issue is unsolved. I can boot into my fresh 18.04 installation but it takes 40 seconds to decrypt the system partition and show the login screen. Most of that time is spent with the fan running high, so I assume the CPU is in use, doing the decrypt. However, when I was debugging the system before using manual chroot from a live disk, cryptsetup open felt almost instantaneous to decrypt the partition and mount the volumes. Any idea how to figure out why it is slow? Anyone else have slow bootup? I'm on an nvme disk with recent core i7, so no hardware reason I can think of.

Cheers,

Jonathan

[Paddy Landau]

Thanks for sharing your solution, Jonathan.

… it takes 40 seconds to decrypt the system partition

I also see this (as noted in the instructions). Obviously, something is going on in the background — perhaps loading all sorts of startup apps, drivers and data?

I'm not entirely sure that this is a problem, because on my (unencrypted) working computer (it's too old to use the encryption process), it takes about a minute to get to the login prompt. But maybe your computer is newer and significantly faster than mine?

I'm not skilled technically. So, if you still require an answer, may I suggest that you raise a new thread in either one of the Security or Installation and Upgrades forums, and post the link here so that we can follow it? The key point to mention is this:

After entering the LUKS passphrase at the Grub prompt, the boot process takes nearly a minute to get to the login screen. Both root and /boot are held in LVM, which is in turn in a partition encrypted by LUKS. If you also have a swap partition, also mention it as being in LVM.

The question is whether or not this process can be shortened.

[flyffies]

Hm, all right. That is not what I expected, but then, as I explained in the instructions, I'm not exactly a technical boffin (almost everything that I did was merely putting together what other people discovered or told me).

I'm going to test this — I might not have time until next week — and I'll get back to you in this thread.

Thanks, I greatly appreciate it!