On Mon, 4 Mar 2024 at 23:28, Steve McIntyre <st...@einval.com> wrote: > > Hey folks, > > On Mon, Mar 04, 2024 at 02:13:25AM +0000, Luca Boccassi wrote: > >On Fri, 19 Nov 2021 09:33:00 +0100 Bastian Blank <wa...@debian.org> > >wrote: > >> Hi > >> > >> I'm rescinding this request. I've got a working prototype, but I > >don't > >> know where this would go. > >> > >> Bastian > > > >The upstream Shim reviewers group now accepts systemd-boot as a 2nd > >stage bootloader, trusted by Shim builds signed with the UEFI 3rd party > >CA. This clears the way for Debian's CA to sign systemd-boot, so I am > >reopening this bug. > > > >shim-review questionnaire update that allows systemd-boot: > > > >https://github.com/rhboot/shim-review/pull/357 > > > >MR on Salsa to add the usual template package, adapted from Bastian's > >MR from a couple of years ago: > > > >https://salsa.debian.org/systemd-team/systemd/-/merge_requests/252 > > > >Debian Shim maintainers, who do we need to seek approvals for this to > >happen? Shim maintainers first of course, anybody else? Release team? > >FTP team? > > OK, I can see what you're doing with templating here, and it looks > clear and obvious. But: this seems to be for standalone systemd-boot > rather than UKI? I thought UKI was the preferred way forward?
When you have a headless system then yeah you can go straight to from a first stage to a UKI - but for any end-user system, sd-boot provides the graphical menu with entry selection and so on, which makes it very desirable for those use cases, so it's the natural first step. UKIs are a mean to ship initrd+kernel, but we need to build the initrd first, and we are quite far from there. I don't know yet how that will look like in details for Debian, we had some ideas, but nothing concrete so far, as it's an infrastructure question. When there's something, it won't be from src:systemd as that just builds the stub component. So I'm starting with the boot menu component, which can already be used with more traditional Type #1 third stages - config file plus signed kernel and ye olde initrd cpio. > I'm a little surprised to see you adding riscv64 stuff - AFAIK there's > nobody (yet) providing any root CA for riscv64? We certainly haven't > done anything with it in Debian yet. We build sd-boot for it, so I added it without thinking - but there's no shim so yeah, there's no point, I've dropped it now, thanks for pointing that out. I see there's an upstream PR for it: https://github.com/rhboot/shim/pull/641 so might add it back if that ends up being built after the next upstream release. > What's your plan for installing as the secondary boot loader for shim > to call? 'bootctl update' already recognises and prefers foo.efi.signed if present, so installing to the ESP is easy (PR still doesn't add the call, will probably add a trigger). But as you know Shim right now compiles in the filename of the second stage, so for now interested testers will have to manually rename the file in the ESP from systemd-bootx64.efi to grubx64.efi, which is of course not ideal - let's call it a technological preview. Fortunately as you might have heard in one of the meetings there's a PR in progress to let Shim be configured at runtime: https://github.com/rhboot/shim/pull/608 I hope we can get that sorted before Trixie freezes, and that's how I see the integration ultimately work. > Modulo those questions, let's talk infrastructure. Off the top of my > head, in no particular order... > > * We'll need to create a new intermediate signing cert for > systemd-boot (and another for UKI, I guess). Given recent > discussions about changing the way we build and sign kernels, we > should also generate a new signer cert for those too. And if we're > going that far, we may as well generate a complete new set of 2024 > certs. [Sorry, rabbithole. :-)] We'll need to talk to DSA about > doing this piece. That makes sense to me, I guess DSA owns the machinery to do this? > * We'll probably need to add things to the signing setup for > ftp-master. Nothing earth-shattering, just some config to > recognise the new set of packages IIRC. I'm sure Bastian can > manage this. :-) > > * Are people from the team ready to deal with long-term security > support for the systemd-boot chain? Speaking for myself, yes, I am already part of the team who is responsible for that upstream, and I plan to be very strict about not carrying downstream patches for the signed components outside of security fixes (and even then, prefer upstream stable point releases that I am also responsible for anyway). > That's all I can think of for now, but I wouldn't be surprised if more > comes to mind tomorrow... :-) Thanks for the feedback!
