Re: [RFC PATCH v2] x86/boot: add .sbat section to the bzImage

[James Bottomley]

On Fri, 2023-07-21 at 13:40 +0100, Luca Boccassi wrote:
> 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?

Well, my job is to be concerned about how individuals who want to own
their own keys, either in MoK or db, participate in this, so I am
mostly thinking about local signing.  Whatever we decide, there must be
a local workflow pathway.

>  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.

There is a thought to get sbat adopted by UEFI to solve the dbx
problem, but if that were to happen, UEFI will likely be extremely
concerned about backward compatibility (and as you have remarked, they
and the OEMs adopt at a glacial pace), so, even if they eventually
adopt it, I can't foresee them mandating refusing to execute signed EFI
binaries with no sbat.  I'll pretty much stake cash on the compromise
being that for the foreseeable future no sbat gets revoked by dbx and
the plan will be a gradual shift towards sbat ... but all this is
contingent on UEFI adoption in the first place, which isn't a given. 
There are also unsolved problems around sbat, like how the master sbat
lists are kept and how they're delivered which must be solved before a
UEFI proposal could be made.

James