Oh man that takes me back. The last time I went down that rabbit hole was ~2015, I tried to implement a "fully encrypted" setup and started with Ubuntu (I know I know). Something something LUKS.
I spent ~2 days tinkering with it and never got it to work, something with the setup flow was totally broken if you also tried to encrypt root (or boot? idk like I said it's been _years_).
I also remember fun problems with grub. I was trying to dual-boot and the windows partition was using hardware-bitlocker (samsung SSD). Some kind of weird interaction was going on between grub, whatever the windows bootloader is called, and my motherboard's EFI I think. Anyways grub ended up fucking bitlocker up and I almost lost all my gaming saves. Had to use some kind of arcane recovery process to get back to being able to even _insert_ the key so the SSD would unlock and windows could continue booting.
Ended up saying screw it after a few days and just going back to windows for my gaming PC, vowing to never try dual-boot again.
More recently, you can even set up GRUB to ask you for the passphrase, so even /boot is encrypted, you only need a tiny 2MB partition at the front to hold the bootloader.
I had to set some kind of kernel flag or something (sorry, it's been years) to get it to ignore the drive until I unlocked it, as there was some kind of tight-loop where it would just keep trying to connect infinitely and not progress/fail/timeout.
I've been meaning to get back into linux again but it's going to be on a pristine/new machine.
That sounds way too exciting, even without that involved I keep my Windows install on its own disk.
With hardware FDE the data written to the raw flash is always encrypted, the AES key is just 0 by default. Macs work this way AFAIK. With "hardware bitlocker" you just change that key (on a fresh drive).
Full performance, better security. Seems awesome huh? Well being outside the happy-path when it comes to hardware configs on free software is just asking for trouble...
This worked fine.
Months later (in this case I just left it connected to a TV and occasionally used it for gaming or whatever) I let it do an OS upgrade and it forgot how to read its disk when it rebooted. I spent maybe 30 minutes trying to fix it (former heavy Gentoo user, so I'm comfortable troubleshooting boot—among other—issues) without making any progress at all, then decided that was the end of that particular check-in with desktop linux. Maybe next time (spoiler: nope, though for different reasons. But maybe the next next time...)
I haven't tried encrypting a Linux root disk since.
Same here - stub, kernel, initrd and embedded cmdline all in a signed UKI on the ESP. I do encrypt my root however, so I wouldn't go as far as "painless" for the grub->efibootmgr switch (but I also switched initramfs generator so... always keep a rescue stick around).
But it's all about ownership and trust. I control the keys - hence I am the owner of my computer - and I don't trust e.g. Microsoft[1] to not eventually try to fuck me over. But that's not the important part.
> Also, I don't understand where remote attestation entered the conversation here, and I also don't see why that can't be a community based thing (al la let's encrypt is now everyone's CA) where you can choose your providers or even roll it yourself.
Remote attestation is mentioned five times in TFA and is where this can get really pernicious - indirectly limiting user choice because $safety_critical_industry (e.g. banking) only allows "the corporate keys" (likely including a few Linuxes too, but something like Gentoo couldn't be). They'll even have very good and completely valid security reasons for not allowing arbitrary user keys, but they'd lock me down to approved choices remotely. A reverse AGPL if you will.
Of course, workarounds will exist: "just multiboot", "just use multiple devices", "just choose the bank that allows you to whitelist your key" (assuming there is one, it's nice to dream) - but user freedom is reduced without malicious intent being strictly necessary anywhere in the process.
That's focusing on the negatives with my paranoiac hat on, of course.
[1] https://www.theregister.com/2022/07/07/lennart_poettering_re...
But regardless, this entire article is about how to have an actually secure boot on Linux (and not remote attestation), something which is certainly good for the user. Otherwise you're actually more easily susceptible to malicious actors stealing your data on the system you "trust". None of the steps listed here require trusting anyone other than the TPM (which is admittedly a flaw so long as we cannot audit them) and you can even use your own keys in pretty much all cases (provided -as discussed in other comments- MS hasn't f'd that up). I personally use a boot-stub based booting method with my own SB keys (but ironically, don't encrypt my root, so go figure), so I can vouch for the fact that it was actually quite painless to setup. Please don't jump down the slippery slope before you actually try these methods and realize that this is just as easy to deploy (you only need to disable secure boot first) and certainly a more secure option than using shim and an unsecured initrd.
Also, I don't understand where remote attestation entered the conversation here, and I also don't see why that can't be a community based thing (al la let's encrypt is now everyone's CA) where you can choose your providers or even roll it yourself.