SBAT feedback

[Paul Moore]

On Thu, Mar 4, 2021 at 11:50 AM Steve McIntyre <steve at einval.com> wrote:
> On Thu, Mar 04, 2021 at 11:20:14AM -0500, Paul Moore wrote:
> >On Thu, Mar 4, 2021 at 10:31 AM Steve McIntyre <steve at einval.com> wrote:
> >
> >> AFAIK almost all of the expected signing targets now have SBAT support
> >> available. We're waiting on some fixes for shim, then a 15.3 release
> >> is due any time now. If you're hoping to get something reviewed and
> >> signed, I'd strongly recommend you move on to that when it's ready.
> >
> >Thanks for the clarification.  I've got a few follow-up questions:
> >
> >* I see a 15.3 shim branch now, is that ready for us to use as a base,
> >or is there still work pending?
>
> AFAICS there are fixes for a few things coming yet, at least:
>
> 1. Signed/unsigned issues around the defintions of CHAR8 in gnu-efi
>
> 2. A problem with varargs in the shim code (including a lump of
>    openssl, of course). EFI/PE calling conventions are quite
>    different, and there are issues.
>
> 3. Header problems - various bits of code are getting the wrong
>    definitions for things like strcmp and not working well.
>
> Peter is doing most of the work here, and I know he'd appreciate more
> help.

Great, thanks for helping set expectations appropriately.

FWIW, I've tried to help with shim (I've landed a couple of PRs,
including some SBAT doc fixes), but some of this goes back to the
private development model - if we don't know what's planned or what
needs fixing, how can we help? :)

> >* Is there any guidance on the SBAT metadata, for example
> >component/vendor names?  I'm happy to just pick values that make sense
> >for our shim build, but I'm guessing the powers that be are going to
> >want to setup a registry somewhere, no?
>
> What we've done so far is use the upstream names for projects, and use
> the UEFI vendor name for vendors, much as in the "Example sbat
> sections" piece in SBAT.md. I know it's not *very* tightly specified,
> but I hope that's clear enough for most users. Does that help?

I suppose.  I'm just trying to avoid a review rejection because of a
naming problem in the SBAT metadata; I suspect many others are going
to have similar questions or concerns.

> >* What about signed vendor key PE files, is that going to be a
> >requirement for new shim review/signing submissions based on 15.3?
>
> Not yet, no. That'll come in a future release.

Ah, good.  Thanks.

> >I apologize for all the questions, but with most of the decisions and
> >development happening in private, it is very hard for most of us to
> >figure out what is going on and what is expected of reviews starting
> >now (or soon).
>
> Nod. :-(
>
> I've not been on top of most of the discussion myself, despite driving
> a lot of Debian's SB stuff. I really want to see development
> discussion opened up much more, and I'm trying to encourage people to
> do that. We had a lot private discussion around the recent GRUB bugs
> that was embargoed, but shim and SBAT discussion did not need to be
> kept under wraps with that.
>
> I think we do have agreement that shim reviews should be done more in
> public, at least.

If nothing else the discussion here has been very helpful, thank you.

-- 
paul moore
www.paul-moore.com