boot: vendor specific location for systemd-boot

[lnussel]

Another heretic topic 😆

No matter how we twist and turn it, systemd-boot is going to be vendor specific one way or another. Especially in secure-boot context it has to have vendor specific SBAT values and a vendor specific signature. It may also have to be installed alongside a vendor specific shim.
So it makes sense for operating system vendors to put systemd-boot into /EFI/$VENDOR instead of the generic /EFI/systemd. The latter could still be used by self compiled versions or upstream builds.

[poettering]

Not grokking the rationale. both shim and and sd-boot support multi-boot scenarios. the former via the mok stuff, the latter naturally via drop-ins. given there's only one generic entrypoint into the system (bootx64.efi) it's hence just creating problems, not solving them by using per-vendor dirs.

Totally not getting this.

[lnussel]

What kind of problems do you see?

I don't feel comfortable competing over the systemd directory with the one of other vendors. To me it makes sense to have a separate boot entry and then just compete over BootOrder.

Correct me if I'm wrong but shim has a specific vendor certificate embedded, so would boot only binaries signed with matching key. Ie the openSUSE shim boots openSUSE. The Fedora one Fedora. Sure you could mess with MokList yourself but that's rather annoying. Also shim has vendor specific patches. I didn't review ours but I'd hope they are there for good reasons.

boot/bootx64.efi is only for removable media resp when Boot entries got messed up, right? On a installed system that binary should actually be any shim, which would restore the real boot entries based on boot.csv files.

Anyway I also wanted to discuss shim integration, I guess I shall file a separate issue for that.

[poettering]

What kind of problems do you see?

I don't feel comfortable competing over the systemd directory with the one of other vendors. To me it makes sense to have a separate boot entry and then just compete over BootOrder.

BootOrder might be interesting for PCs, but I'd never rely on it exclusively. First of all on VMs and stuff it's pretty much irrelevant (generic images are typically booted via BOOTX64.EFI) but it's also a bit fragile.

The whole logic in bootctl is written so that we can safely update the boot loader, i.e. it does version strings and such. Hence, yes, builds might differ between distros, but as long as they don't do so too wildly things should be fine.

Correct me if I'm wrong but shim has a specific vendor certificate embedded, so would boot only binaries signed with matching key. Ie the openSUSE shim boots openSUSE. The Fedora one Fedora. Sure you could mess with MokList yourself but that's rather annoying. Also shim has vendor specific patches. I didn't review ours but I'd hope they are there for good reasons.

I'd advise distros that want shim-based multiboot to work sanely to not depart too much from upstream shim/sd-boot, and to always provide their keys also via mok, so that a single menu can be compiled from all participants and booted safely. Yes, shim will come with built-in keys, but others can play ball by adding their keys too.

boot/bootx64.efi is only for removable media resp when Boot entries got messed up, right? On a installed system that binary should actually be any shim, which would restore the real boot entries based on boot.csv files.

I think that's a bad idea. Booting an OS from removable media or a random image should not alter the system's NVRAM for good.

[lnussel]

Lennart Poettering wrote:

What kind of problems do you see? I don't feel comfortable competing over the |systemd| directory with the one of other vendors. To me it makes sense to have a separate boot entry and then just compete over BootOrder. BootOrder might be interesting for PCs, but I'd never rely on it exclusively. First of all on VMs and stuff it's pretty much irrelevant (generic images are typically booted via BOOTX64.EFI) but it's also a bit fragile.

Yes, for VMs and images the issue at hand does not matter indeed. This is about scenarios where more than one vendor wants to use the boot partition.

The whole logic in bootctl is written so that we can safely update the boot loader, i.e. it does version strings and such. Hence, yes, builds might differ between distros, but as long as they don't do so too wildly things should be fine.

I have to assume that wild things will happen. To the very least the openSUSE systemd-boot will have a green menu :-) Actually when playing with the script solution I was thinking to even make the vendor dir not a static vendor dir but a per instance, versioned directory. That would actually allow to map bootloader updates to snapshots and also implement rollback for the bootloader.

|boot/bootx64.efi| is only for removable media resp when Boot entries got messed up, right? On a installed system that binary should actually be any shim, which would restore the real boot entries based on |boot.csv| files. I think that's a bad idea. Booting an OS from removable media or a random image should not alter the system's NVRAM for good.

Sure. Removable media would not have the vendor dir, hence no fallback.efi nor boot.csv hence no nvram altering. As described in #27234

[lnussel]

closing to continue discussion in #27234