Bug#996202: EFI Secure Boot for systemd-boot
On Fri, 10 May 2024 at 15:49, Steve McIntyre wrote: > > On Fri, May 10, 2024 at 03:44:35PM +0100, Luca Boccassi wrote: > >On Fri, 10 May 2024 at 15:36, Steve McIntyre wrote: > >> On Fri, May 10, 2024 at 04:29:00PM +0200, Ansgar wrote: > >> > >> >Maybe we should use a non-trusted cert for the initial setup and only > >> >switch to a proper cert once everything is confirmed to be working as > >> >expected? > >> > >> Hmmm, maybe? Luca? > > > >What do you mean precisely here? A DSA-managed cert used by FTP to > >sign but that doesn't chain to the Debian CA? Or to do something > >completely local to the systemd-boot package? > > Exactly the former - we can use a test key for signing systemd-boot to > start with. Once we're happy all round, we can switch to a cert in the > chain. > > >I am fine with any approach that lets us move forward, if that needs > >to be some intermediate testing stage that's fine by me. > > Cool. Ok, sounds good to me, thanks. DSA, now that FTP Team has acked with this suggestion to use a test cert first, are you happy to proceed or is there anything else you need from me? Thanks!
Bug#996202: EFI Secure Boot for systemd-boot
On Fri, May 10, 2024 at 03:44:35PM +0100, Luca Boccassi wrote: >On Fri, 10 May 2024 at 15:36, Steve McIntyre wrote: >> On Fri, May 10, 2024 at 04:29:00PM +0200, Ansgar wrote: >> >> >Maybe we should use a non-trusted cert for the initial setup and only >> >switch to a proper cert once everything is confirmed to be working as >> >expected? >> >> Hmmm, maybe? Luca? > >What do you mean precisely here? A DSA-managed cert used by FTP to >sign but that doesn't chain to the Debian CA? Or to do something >completely local to the systemd-boot package? Exactly the former - we can use a test key for signing systemd-boot to start with. Once we're happy all round, we can switch to a cert in the chain. >I am fine with any approach that lets us move forward, if that needs >to be some intermediate testing stage that's fine by me. Cool. -- Steve McIntyre, Cambridge, UK.st...@einval.com Mature Sporty Personal More Innovation More Adult A Man in Dandism Powered Midship Specialty
Bug#996202: EFI Secure Boot for systemd-boot
On Fri, 10 May 2024 at 15:36, Steve McIntyre wrote: > > On Fri, May 10, 2024 at 04:29:00PM +0200, Ansgar wrote: > >Hi, > > > >On Fri, 2024-05-10 at 15:20 +0100, Luca Boccassi wrote: > >> On Thu, 04 Apr 2024 20:41:59 +0100 Luca Boccassi > >> > On IRC Steve mentioned that he's ok with proceeding with this. > >> > jcristau from DSA said that it's the FTP team that should confirm the > >> > request > >> > for the new intermediate signer cert for systemd-boot to DSA. > >> > > >> > FTP team, are you ok with proceeding with this? If so, would it be > >> > possible to have an ACK, please? Is there any more information required > >> > beforehand? > > > >As long as the security boot people are fine with this, I think this > >should be fine. (And AFAIU this seems to be the case.) > > Yes, I'm happy for us to add this. Please go ahead. > > >Maybe we should use a non-trusted cert for the initial setup and only > >switch to a proper cert once everything is confirmed to be working as > >expected? > > Hmmm, maybe? Luca? What do you mean precisely here? A DSA-managed cert used by FTP to sign but that doesn't chain to the Debian CA? Or to do something completely local to the systemd-boot package? I am fine with any approach that lets us move forward, if that needs to be some intermediate testing stage that's fine by me.
Bug#996202: EFI Secure Boot for systemd-boot
On Fri, May 10, 2024 at 04:29:00PM +0200, Ansgar wrote: >Hi, > >On Fri, 2024-05-10 at 15:20 +0100, Luca Boccassi wrote: >> On Thu, 04 Apr 2024 20:41:59 +0100 Luca Boccassi >> > On IRC Steve mentioned that he's ok with proceeding with this. >> > jcristau from DSA said that it's the FTP team that should confirm the >> > request >> > for the new intermediate signer cert for systemd-boot to DSA. >> > >> > FTP team, are you ok with proceeding with this? If so, would it be >> > possible to have an ACK, please? Is there any more information required >> > beforehand? > >As long as the security boot people are fine with this, I think this >should be fine. (And AFAIU this seems to be the case.) Yes, I'm happy for us to add this. Please go ahead. >Maybe we should use a non-trusted cert for the initial setup and only >switch to a proper cert once everything is confirmed to be working as >expected? Hmmm, maybe? Luca? Also, while I'm thinking about things... We should probably also move to a new kernel signing cert for unstable/testing now that we've moved to build-time ephemeral keys for the modules. At some point in the future that will let us DBX-block the old kernel signing certificate(s) in a new shim build. Bastian: I'm assuming the ephemeral change is only a thing in testing/unstable? Can we (easily) use a different signer for different releases of the kernel here? In fact, if we're going to generate new keys and certs for the intermediate signers, it might be worth refreshing them all anyway maybe? -- Steve McIntyre, Cambridge, UK.st...@einval.com "Every time you use Tcl, God kills a kitten." -- Malcolm Ray
Bug#996202: EFI Secure Boot for systemd-boot
Hi, On Fri, 2024-05-10 at 15:20 +0100, Luca Boccassi wrote: > On Thu, 04 Apr 2024 20:41:59 +0100 Luca Boccassi > > On IRC Steve mentioned that he's ok with proceeding with this. > > jcristau from DSA said that it's the FTP team that should confirm the > > request > > for the new intermediate signer cert for systemd-boot to DSA. > > > > FTP team, are you ok with proceeding with this? If so, would it be > > possible to have an ACK, please? Is there any more information required > > beforehand? As long as the security boot people are fine with this, I think this should be fine. (And AFAIU this seems to be the case.) Maybe we should use a non-trusted cert for the initial setup and only switch to a proper cert once everything is confirmed to be working as expected? Ansgar
Bug#996202: EFI Secure Boot for systemd-boot
On Thu, 04 Apr 2024 20:41:59 +0100 Luca Boccassi wrote: > On Fri, 22 Mar 2024 18:13:35 + Luca Boccassi > wrote: > > On Mon, 4 Mar 2024 at 23:58, Luca Boccassi wrote: > > > > > > On Mon, 4 Mar 2024 at 23:28, Steve McIntyre > wrote: > > > > > > > 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! > > > > Gentle ping on this - what are the next steps in order to make this > happen? > > On IRC Steve mentioned that he's ok with proceeding with this. jcristau > from DSA said that it's the FTP team that should confirm the request > for the new intermediate signer cert for systemd-boot to DSA. > > FTP team, are you ok with proceeding with this? If so, would it be > possible to have an ACK, please? Is there any more information required > beforehand? > > Thanks! Hello FTP Team, One more gentle ping to unblock progress on this. TIA! -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#996202: EFI Secure Boot for systemd-boot
On Fri, 22 Mar 2024 18:13:35 + Luca Boccassi wrote: > On Mon, 4 Mar 2024 at 23:58, Luca Boccassi wrote: > > > > On Mon, 4 Mar 2024 at 23:28, Steve McIntyre wrote: > > > > > 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! > > Gentle ping on this - what are the next steps in order to make this happen? On IRC Steve mentioned that he's ok with proceeding with this. jcristau from DSA said that it's the FTP team that should confirm the request for the new intermediate signer cert for systemd-boot to DSA. FTP team, are you ok with proceeding with this? If so, would it be possible to have an ACK, please? Is there any more information required beforehand? Thanks! -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#996202: EFI Secure Boot for systemd-boot
On Mon, 4 Mar 2024 at 23:58, Luca Boccassi wrote: > > On Mon, 4 Mar 2024 at 23:28, Steve McIntyre wrote: > > > 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! Gentle ping on this - what are the next steps in order to make this happen?
Bug#996202: EFI Secure Boot for systemd-boot
On Sat, 9 Mar 2024 at 09:59, Pascal Hambourg wrote: > > On 05/03/2024 at 00:58, Luca Boccassi wrote: > > On Mon, 4 Mar 2024 at 23:28, Steve McIntyre wrote: > >> > >> 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. > > What about the installation of shim files into the ESP along with > systemd-boot ? Does bootctl take care of it ? If no, are there any plans > to integrate it ? It does not, there are plans to extend it to do so but it needs 2 things to happen in shim first: - support runtime configuration of second stage, rather than just build time - ie, we definitely do not want our tools to install 'grubx64.efi' as that would be invading someone else's namespace - support providing a version in the PE header so that updates can be done too, not just first installations https://github.com/systemd/systemd/pull/27322 > Also, are there any plans to support multiple ESPs for boot redundancy > (e.g. in software RAID setups) ? It's been asked multiple times, but nobody implemented it so far: https://github.com/systemd/systemd/issues/29948 https://github.com/systemd/systemd/issues/3252 Thing is, because the ESP content is trivial and can be recreated from packages every time if needed, it's not really a very interesting use case for us. if someone wants to do the work to get bootctl to duplicate the content and keep it in sync we can review it and there's no opposition in principle to have it, but we (core devs) are not going to implement it, someone who cares about the use case needs to do so.
Bug#996202: EFI Secure Boot for systemd-boot
On 05/03/2024 at 00:58, Luca Boccassi wrote: On Mon, 4 Mar 2024 at 23:28, Steve McIntyre wrote: 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. What about the installation of shim files into the ESP along with systemd-boot ? Does bootctl take care of it ? If no, are there any plans to integrate it ? Also, are there any plans to support multiple ESPs for boot redundancy (e.g. in software RAID setups) ?
Bug#996202: EFI Secure Boot for systemd-boot
On Mon, 4 Mar 2024 at 23:28, Steve McIntyre wrote: > > Hey folks, > > On Mon, Mar 04, 2024 at 02:13:25AM +, Luca Boccassi wrote: > >On Fri, 19 Nov 2021 09:33:00 +0100 Bastian Blank > >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!
Bug#996202: EFI Secure Boot for systemd-boot
Hey folks, On Mon, Mar 04, 2024 at 02:13:25AM +, Luca Boccassi wrote: >On Fri, 19 Nov 2021 09:33:00 +0100 Bastian Blank >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? 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. What's your plan for installing as the secondary boot loader for shim to call? 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. * 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? That's all I can think of for now, but I wouldn't be surprised if more comes to mind tomorrow... :-) -- Steve McIntyre, Cambridge, UK.st...@einval.com Into the distance, a ribbon of black Stretched to the point of no turning back
Bug#996202: EFI Secure Boot for systemd-boot
On Fri, 19 Nov 2021 09:33:00 +0100 Bastian Blank 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? -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
