On Fri, 21 Jul 2023 at 12:24, James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> wrote: > > 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. Are you sure that's not just about local signing? IE, MoK vs embedded cert auth flow? As far as I know, the plan for the 3rd party CA flow is to eventually (very eventually) require it. I might have missed some development ofc.
