On Fri, 2023-07-21 at 09:55 +0100, Luca Boccassi wrote: > On Fri, 21 Jul 2023 at 02:49, Eric Snowberg > <eric.snowberg@xxxxxxxxxx> wrote: > > > On Jul 20, 2023, at 1:16 PM, Luca Boccassi <bluca@xxxxxxxxxx> > > > wrote: > > > On Thu, 20 Jul 2023 at 18:11, Eric Snowberg > > > <eric.snowberg@xxxxxxxxxx> wrote: [...] > > > > I agree with James in the previous thread; adding the SBAT > > > > section to the kernel should be handled by the signing tools. > > > > It really doesn't need to be included in the mainline kernel > > > > code. I also agree with the sentiment that mainline and the > > > > stable branches should not have SBAT versions attached > > > > to them. These are things distros should be responsible for > > > > including in their kernel if they want to have SBAT support. > > > > > > Why would 'signing tools' handle that? It's just a text-based PE > > > section, it doesn't require access to private key materials to be > > > handled, nor it has any relationship with signing. > > > > There is a relationship, the sbat information within the signed > > file can be used for revocation in lieu of revoking the hash or > > signing certificate at a later time. > > No, it is completely disjoint. In fact, the kernel doesn't even have > to be signed at all, but it still _must_ have a .sbat section when it > is used in a UKI. Just a minute, this is wrong. I was talking to Peter after all of this blew up about how we handle signed kernels with no sbat (since we need that still to work for developers who sign their own kernels). I thought he was planning to require an sbat section for all EFI binaries, but he says that's not true. The current way shim does the sbat check is that if the section doesn't exist the binary is processed as having an empty sbat section (i.e. no sbat level checking will be done because there's no named sbat level for anything and it will just work) and they're planning to keep it that way so that a signed but no sbat kernel will always "just work" without any special key handling in shim. So if we're planning to keep this no-sbat case in discrete kernels, even when the shim verifier checks sbat, the UKI kernel will need to work for this case as well. James
