I fail to see what all the panic is about. All of the SystemD tools mentioned here (iirc) don't actually rely much on SystemD proper and especially systemd-boot and the boot stub are just SystemD in name (I use both).
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.
> I personally use a boot-stub based booting method with my own SB keys
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.
> but ironically, don't encrypt my root, so go figure
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.
Huh? I've been using LUKS for FDE (with unencrypted /boot) way before 2015, and it's never been a problem. Debian has offered an option to set it up during installation, and it was 100% smooth sailing from there.
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.
Well I remember getting completely stuck at one part and the cause was my samsung SSD's funny behavior in the "locked" state.
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.
Well the work is in setting it up. Once it's working you just enter a password. I'm sure hardware FDE support in linux has come a long way since I last tried.
There shouldn't be that level of work required to set it up. The tools are lacking if it's not just a couple of commands or toggles to get a fully encrypted disk with a secure boot chain.
A couple times ago when I poked my head back in on my old pal, the Linux Desktop, to see how it was doing, I picked Ubuntu, and, because I'd gotten used to it on Mac, selected disk encryption at install.
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.
I mean I love the idea right? Software FDE comes with a performance hit, as well as increased wear on the SSD.
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...
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.