Encrypting disks, especially on laptops, seems like a no-brainer these days. There are plenty of stories of laptops being lost or stolen with important information stored on them (medical records, financial information). To me this is about the peace of mind: I don’t want to care too much about losing equipment if I only know the data stored on it cannot be accessed (easily). Of course with enough effort, expertise and the right equipment, it’s likely possible to recover encrypted data, but I assume I’m not the target.
I also do not need all the bootloader hurdles along the way and prefer simplicity: boot straight into Linux kernel from UEFI, directly.
I do like the idea of self- (always) encrypting drives. It’s very convenient and transparent, also with regards to disk I/O performance. There’s nothing required to encrypt data, as it is encrypted all the time by default. The key is to only lock the disk when powered off, which is enabled by setting a password. This is also convenient for having full-system encryption, which typically is not trivial when using software solutions like LUKS (boot and possibly system partitions are left not encrypted, mostly for simplicity).
I do have a bad experience with self-encrypting drive which was used as an experiment in a self-built FreeNAS box. FreeNAS offered storing the disk password and unlocking the disk on start-up which seemed to work great. One day though, possibly after a power outage, it started to misbehave. After one or two reboots, the disk no longer accepted the password and remained locked.
Anyway, maybe that was not the right use of the self-encrypted drive. For laptops though, it seems like a good choice, at least for me. What matters next is the (in)convenience of entering the disk password during boot. A “generic” laptop may not have support in its boot firmware (aka BIOS/UEFI) for self-encrypted drives, so in that case what I ended up with is this (Tuxedo laptop):
- power-on (BIOS/UEFI) password
- disk password
- (re)boot (BIOS/UEFI) password
The disk itself is unlocked with a UEFI PBA. I followed the instructions on the Drive Trust Alliance website.
What I found on my ThinkPad P52 though turned out to be much more convenient: not only it supports unlocking self-encrypted drives in its BIOS/UEFI, but also has a fingerprint reader. Personally I consider bio-metric authentication inferior to passwords, but most of the time it’s fine and yet very convenient. The advantage of fingerprint authentication in my opinion is apparent in the presence of pervasive CCTV, and possibly other people peeking over my shoulder when typing in the password. So I end up typing in no passwords at all for power-on, disk and (re)boot authentication.
Disk(s) without self-encryption feature
As much as my ThinkPad is convenient, I found that its second disk is not
self-encrypting. This turns out not to be a big problem: I decided to use it
/home partition and encrypt with LUKS with a random 4096B key stored on
the self-encrypted disk used for all other (boot, system etc.) partitions.
I tried to remove as many steps from the boot sequence as possible, so I also
decided not to bother with GRUB. On my “production” laptop I do not tend to
experiment with my own-built Linux kernels nor tweak boot parameters. The last
time I needed this, I used
kexec which I also found way much convenient.
I took even a step further, and gave up on any bootloader and instead boot Linux
directly from UEFI, thanks to the UEFI stub. These days I’m using Arch Linux
which by default provides Linux kernels with UEFI stub enabled, so that’s even
easier. With the EFI partition mounted as
/boot, it also becomes transparent
for the system updates when it comes to upgrading the Linux kernel.
Installing Arch Linux
Given the above, here’s a brief list of steps I took to create my best (so far) laptop installation.
Since this was on my ThinkPad P52, I configured power-on, (re)boot and disk passwords in its BIOS set-up/configuration (Enter to interrupt normal start-up, Enter to keep the menu, F1). For the fingerprint reader, I might have set it up (trained) in Windows when I still had it originally installed. Not sure how much of a problem this might be without Windows whatsoever. For the other laptop (Tuxedo), I could only set power-on and (re)boot passwords while for the disk password I followed the instructions on the Drive Trust Alliance website.
More details on installing Arch Linux are available in its installation guide. Here is the gist of it, relevant to my installation. I skipped all the usual steps.
Optional vconsole locking
Since I don’t like to leave my laptop unlocked, and it might take a while to download and install packages, I had to the following on the Arch Liux installer system:
- set the root password
Then I was able to use
vlock -a from the other virtual terminal.
First, I listed the disks/partitions:
From this point, I assumed these disks:
/dev/nvme0n1- non-OPAL (no FDE)
/dev/nvme1n1- OPAL (FDE)
First disk (non-OPAL) dedicated as
Second disk (OPAL):
Next step was formatting the partitions:
Mounted the “FDE” partitions:
The last step was to encrypt the non-OPAL disk:
What followed was a typical installation and configuration steps, not so much
interesting here. What’s important here is to include
efibootmgr in the list
of installed packages so it’s available in
Boot manager (EFISTUB)
chroot-environment, here’s how I configured UEFI to boot my new
Arch Linux installation.
First, I dumped the list of partitions into a file:
Next, I edited
cmd.sh so it ended up looking something similar to below, with
“XXX…” bits replaced with the boot partition UUID:
Then I executed the script and removed it, as it’s no longer needed:
And that’s it, voilà! Now the system should boot straight from UEFI into the new Arch Linux kernel.
This is just yet another option for setting up disk encryption and partitioning. This seems to work very well for me, and so far is the best I’ve come up with so far. Far on the horizon might be trying the same with Alpine Linux, but for now I stick with Arch Linux.