scyhmmm since I'll be using #debootstrap anyway, I might as well use systemd-boot instead of grub … 🤔
Fixstern@scy go for it, configuration of that thing is sooo much cleaner than grub (and you can save another entry as the default entry by just pressing "d" in the boot menu)
@dunkelstern I'll need to roll my own Secure Boot keys in that case though, right? Something I was hoping to avoid.
Nik | Klampfradler 🎸🚲@scy @dunkelstern Why would you?
@nik @dunkelstern Because Debian's GRUB is signed, but its systemd-boot is not.
@scy @dunkelstern Both shoul use the SHIM loader. I always simply install systemd-boot and it works.
@nik @dunkelstern Hm. Wouldn't be surprised if the wiki is simply outdated. I'll play around with it and see whether it indeed works, thanks!
@scy @dunkelstern The Debian Wiki is one of the worst examples for a wiki, so yes ;).
GD2@scy @dunkelstern Wait, how so, is there a pre-signed GRUB? sd-boot should also work with shim if you are referring to that, though I never tried it.
Self-signing is advantageous (in your case) though, as that is probably the only way you can verify your initramfs as well?
@gd2 @dunkelstern Yes, according to https://wiki.debian.org/SecureBoot#Supported_architectures_and_packages Debian comes with pre-signed GRUB and kernel, shim is also available.
I'm kind of a noob when it comes to how SB works, but the way I understand it, since sd-boot only works with UKIs, I need to combine Debian's signed kernel and initramfs into a UKI and thus self-sign anyway.
@scy @dunkelstern Ah sorry, then I skipped a lot of steps in my initial reply.
So from the wiki page, only shim is signed by Microsoft, the others (including GRUB) are signed by Debian, which tracks with what I know. So the Microsoft signed shim is required if you want to use SB but not roll your own keys, as most consumer hardware has only the Microsoft CA installed and not the Debian one. Instead, shim contains the Debian CA and then verifies the Debian signed GRUB, I believe. [1/3]
@scy @dunkelstern I believe shim also allows you to upload your own CA of sorts to sign things, so you have two ways of rolling your own keys, directly with the firmware (the only way I have done so far) or with shim.
sd-boot doesn't only work with UKIs, it still supports kernel + initramfs! This also works with SB, but then only the kernel is verified, so if you only sign the kernel (as Debian does) you have a weaker form of protection, the initrd can be modified. [2/3]
@scy @dunkelstern Having shim load sd-boot seems to work, but it is kind of a hack as you have to rename sd-boot to "grubx64.efi" because that is what shim expects. So it is doable but probably requires some manual attention on upgrades.
There is a different problem though: I don't see sd-boot in the list of Debian signed packages. So the shim won't actually verify sd-boot unless you sign it and upload your key to the shim, at which point you are kind of rolling your own keys anyway... [3/3]
@gd2 @scy The question is basically: Do you need full secure boot or do you just want it to boot a kernel and keep it activated because of windows dual boot or something. If you just want it to work: use "preloader" it will chain load any boot manager and will error out when the kernel changes and present you a menu to enroll the kernel on the spot (which kinda defeats the purpose when your thread model is a person having access to the computer) it prevents booting with automated changes only
@gd2 @scy The archlinux wiki has documentation for shim and preloader in combination qith anything. Preloader is the most "install and forget" method as you do not need to handle keys or make sure to sign everything all the time, it may happen that you get a red "hash changed" error on boot but if hashtool is available you can just enroll the kernel at that time and trigger a reload. ( https://wiki.archlinux.org/title/Unified_Extensible_Firmware_Interface/Secure_Boot )