From steve at einval.com  Thu Mar  4 15:24:13 2021
From: steve at einval.com (Steve McIntyre)
Date: Thu, 4 Mar 2021 15:24:13 +0000
Subject: SBAT patch for fwupdate
Message-ID: <20210304152404.GU5283@tack.einval.com>

Hey folks,

One of the changes that's come out of the latest set of GRUB updates
and attendant Secure Boot revocations is SBAT (Secure Boot Advanced
Targeting - see https://github.com/rhboot/shim/blob/main/SBAT.md).
This necessitates all signed binaries to now include an extra lump of
metadata so that generation-based revocation can work.

Shim, GRUB and fwupd all have support for this now, which is good. For
older distros still shipping fwupdate as a separate signed package,
there's not been an upstream fix for this as the project is now dead
and merged into fwupd. So I've added a simple patch for this for the
sake of Debian, and AIUI Javier has reviewed it and is expecting to
adopt it for RHEL7.

Here's the link in case anybody else is interested:

  https://github.com/steve-mcintyre/fwupdate/commit/be48c87244643bd6da4e2badfc9f85c33c97a376

-- 
Steve McIntyre, Cambridge, UK.                                steve at einval.com
'There is some grim amusement in watching Pence try to run the typical
 "politician in the middle of a natural disaster" playbook, however
 incompetently, while Trump scribbles all over it in crayon and eats some
 of the pages.'   -- Russ Allbery



From steve at einval.com  Thu Mar  4 15:30:58 2021
From: steve at einval.com (Steve McIntyre)
Date: Thu, 4 Mar 2021 15:30:58 +0000
Subject: SBAT feedback
In-Reply-To: <CAHC9VhRFXr6ttuHdVE5M5vXCY4z-odJg5DnQurNrhmsuXFqL5g@mail.gmail.com>
References: <20210201201901.GO4886@tack.einval.com>
 <CAHC9VhRFXr6ttuHdVE5M5vXCY4z-odJg5DnQurNrhmsuXFqL5g@mail.gmail.com>
Message-ID: <20210304153058.GV5283@tack.einval.com>

Hi Paul!

Apologies for not responding sooner, along with lots of other people
I've been tied up with the GRUB fixes and related work for the last
couple of weeks. :-/

On Wed, Feb 24, 2021 at 11:56:45AM -0500, Paul Moore wrote:
>On Mon, Feb 1, 2021 at 3:19 PM Steve McIntyre <steve at einval.com> wrote:
>> Hey folks,
>>
>> Talking about the SBAT design in
>>
>>   https://github.com/rhboot/shim/blob/sbat/SBAT.md
>>
>> I'm thinking the mailing list would be a good place to take discussion
>> of the design document ...
>
>I'm currently working my way through the SBAT.md doc so no real
>comments from me, but I do have a question - one that I suspect a lot
>of folks will have if they don't already: when are new shim
>review/signing submissions going to be required to use this new
>approach?  For example, can I submit a shim review this week, based on
>the 15.2 branch, or do all shim review submissions from this point on
>require the submission utilize SBAT?

AIUI, at this point Microsoft are not going to be happy signing
anything without SBAT now. That's likely going to make some people
unhappy, but the ever-diminishing space for DBX updates is terrifying
people.

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.

Cheers,

Steve

-- 
Steve McIntyre, Cambridge, UK.                                steve at einval.com
"...In the UNIX world, people tend to interpret `non-technical user'
 as meaning someone who's only ever written one device driver." -- Daniel Pead



From paul at paul-moore.com  Thu Mar  4 16:20:14 2021
From: paul at paul-moore.com (Paul Moore)
Date: Thu, 4 Mar 2021 11:20:14 -0500
Subject: SBAT feedback
In-Reply-To: <20210304153058.GV5283@tack.einval.com>
References: <20210201201901.GO4886@tack.einval.com>
 <CAHC9VhRFXr6ttuHdVE5M5vXCY4z-odJg5DnQurNrhmsuXFqL5g@mail.gmail.com>
 <20210304153058.GV5283@tack.einval.com>
Message-ID: <CAHC9VhRmhYG-2nKTEiyuA8bBgExiBLxUwBYrcxiiSiadpfRGag@mail.gmail.com>

On Thu, Mar 4, 2021 at 10:31 AM Steve McIntyre <steve at einval.com> wrote:
>
> Hi Paul!

Hi :)

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

* 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 about signed vendor key PE files, is that going to be a
requirement for new shim review/signing submissions based on 15.3?

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

-- 
paul moore
www.paul-moore.com


From steve at einval.com  Thu Mar  4 16:49:23 2021
From: steve at einval.com (Steve McIntyre)
Date: Thu, 4 Mar 2021 16:49:23 +0000
Subject: SBAT feedback
In-Reply-To: <CAHC9VhRmhYG-2nKTEiyuA8bBgExiBLxUwBYrcxiiSiadpfRGag@mail.gmail.com>
References: <20210201201901.GO4886@tack.einval.com>
 <CAHC9VhRFXr6ttuHdVE5M5vXCY4z-odJg5DnQurNrhmsuXFqL5g@mail.gmail.com>
 <20210304153058.GV5283@tack.einval.com>
 <CAHC9VhRmhYG-2nKTEiyuA8bBgExiBLxUwBYrcxiiSiadpfRGag@mail.gmail.com>
Message-ID: <20210304164923.GY5283@tack.einval.com>

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.

>* 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?

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

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

-- 
Steve McIntyre, Cambridge, UK.                                steve at einval.com
Can't keep my eyes from the circling sky,
Tongue-tied & twisted, Just an earth-bound misfit, I...



From paul at paul-moore.com  Thu Mar  4 23:34:46 2021
From: paul at paul-moore.com (Paul Moore)
Date: Thu, 4 Mar 2021 18:34:46 -0500
Subject: SBAT feedback
In-Reply-To: <20210304164923.GY5283@tack.einval.com>
References: <20210201201901.GO4886@tack.einval.com>
 <CAHC9VhRFXr6ttuHdVE5M5vXCY4z-odJg5DnQurNrhmsuXFqL5g@mail.gmail.com>
 <20210304153058.GV5283@tack.einval.com>
 <CAHC9VhRmhYG-2nKTEiyuA8bBgExiBLxUwBYrcxiiSiadpfRGag@mail.gmail.com>
 <20210304164923.GY5283@tack.einval.com>
Message-ID: <CAHC9VhSTuzxT1BxVfc_UfLd=QcSzDR45W4aWvWqKsxnJGn3kdg@mail.gmail.com>

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