openSUSE Tumbleweed Adds systemd-boot Support

[J.King]

Great news! I've tried switching my installation of TW to systemd-boot a just a few weeks ago, but it was so fiddly I reverted back soon after. I've been using systemd-boot on my Gentoo box for years now, and I find the overall experience with it much more pleasant that GRUB.

Hear, hear. I've been using systemd-boot on my Arch desktop for a few months now, and it's like night and day. Easy to use, easy to configure. The bootloader may be a minuscule part of the system, but it's a very visible part, and GRUB comes off as very creaky.

[dremon_nl]

No, the open suse setup is actually with encrypted /boot, so grub decrypts /boot BEFORE initramfs gets loaded. Hence my question if systemd boot works with that kind of setup.

sd-boot doesn't use /boot partition. Kernel (with initrd) is copied to ESP and booted directly. Initrd then asks the user for the password and decrypts the LUKS partition.

[user1]

Clearly seemed to be a joke to me, though not a particularly funny one.

Even if it was really a joke, it's not a clear one because in the Linux world virtually anything can be both loved or hated by different users.

[drake23]

sd-boot doesn't use /boot partition. Kernel (with initrd) is copied to ESP and booted directly. Initrd then asks the user for the password and decrypts the LUKS partition.

Thanks, so it can't do what GRUB currently can. Hoping this gap will be closed so feature parity is reached and it is really a valid choice

[andyprough]

Tantrum distro for tantrum people

I don't use Artix dinit, but I can pretty much guarantee that it will run significantly faster than anything you are running, unless you are running something like a custom gentoo rig with s6. It's not a tantrum distro by any stretch of the imagination, it's a distro that's designed for exceptional speed, and it's supported by the larger Arch developer community, just as the openrc variants have been for a significant number of years.

[User42]

No, the open suse setup is actually with encrypted /boot, so grub decrypts /boot BEFORE initramfs gets loaded. Hence my question if systemd boot works with that kind of setup.

I am not sure this is the default way tw is doing things plus this setup has been overseeded by a more secure one (efi + secure boot + unified kernels).

What's the point of encrypting /boot if I can replace grub with my evil version (it's as easy as replacing the kernel) and, even if you have secure boot enabled, if I can craft an encrypted partition that will exploit your existing grub?

Arguably, this is harder but grub does not run under the kernel: there is about 0 vulnerability mitigation and its surface of attack is very large (so we have luks, dm-crypt, different forks of different file systems, probably other interesting modules too). Finding exploits is not far fetched... And all of this for what? To hack together what can be cleanly implemented today under EFI with no bootloader at all (just EFI entries) or a simple one...

The additional advantage is that such simpler boot types tend not to fail as much as grub does (just have a look on any distro's reddit to see at least a dozen "my computer does not boot" and variations systematically solved by booting on a livecd and running grub-mkconfig again).

[User42]

Thanks, so it can't do what GRUB currently can. Hoping this gap will be closed so feature parity is reached and it is really a valid choice

It's not because you don't know how things can be done that they can't be done.

[drake23]

User42 Thanks for taking the time to respond!

The encrypted boot setup was the default when I installed leap 15.3 back in the day (now upgraded to the, but the setup still holds).

How would one move the SSD to another system when secure boot comes into play?

I think my point is that I do trust software more that uefi/hw implementations when it comes to security. And one should know by now that code signing is not that effective if keys leak out (looking at ms/azure recently)

[t.s.]

Great news! I've tried switching my installation of TW to systemd-boot a just a few weeks ago, but it was so fiddly I reverted back soon after. I've been using systemd-boot on my Gentoo box for years now, and I find the overall experience with it much more pleasant that GRUB.

I want to use systemd-boot too, but with btrfs and snapshots. And it looks like there's no easy way to set up that.

[User42]

User42
The encrypted boot setup was the default when I installed leap 15.3 back in the day (now upgraded to the, but the setup still holds).

How would one move the SSD to another system when secure boot comes into play?

I think my point is that I do trust software more that uefi/hw implementations when it comes to security. And one should know by now that code signing is not that effective if keys leak out (looking at ms/azure recently)

The modern way of doing trusted computing on the desktop/laptop is to separate concerns as much as possible.

The system is something you can backup/restore or redeploy. The only thing you want to make sure of is that what you boot is what *you* have put in place. This is usually done by encrypting `/` (but dm-verity could work very well there too!) and make sure that your boot chain is *exactly* what you think it is so upon installation, you sign a unified kernel and all the bootloader machinery to make sure the system is exactly in a state you control (with Secure Boot and possibly TPM decryption).

Breaking that would require either a compromised firmware (in which case you are screwed, whatever you do, even "in software"). If we assume the firmware is not compromised, a motivated party would have to steal you computer, make sure they do not trigger chassis intrusion detectors, remove most of the hardware from the computer, desolder the tpm, mill it, use an electron microscope to put probes down, measure everything on boot and then, to avoid being caught, would have to reprogram another TPM to contain exactly the same information. If the TPM is included in the CPU, that's what you have to deal with.


If the alternative is having unsigned grub decrypt your root fs, compromising such system is trivial. I really mean it. All you have to do is boot another system (either by "borrowing" the SSD for a couple minutes or by pressing F12) and replace grub with an evil version.

To make sure what you boot is what you intended, you need hardware, software alone won't bring you far.

And before you object hw can't be trusted and could leak out your keys, it's the same for a pure software solution.

Don't get fooled by grub not being on a mountable partition in legacy BIOS systems. It's as easily accessible as grub itself on a efi fat partition.