SBAT feedback

[Steve McIntyre]

Hey Jan!

On Mon, Feb 01, 2021 at 09:59:00PM +0000, Jan Setje-Eilers wrote:
>>In the summary, there are two solutions outlined
>>
>>1. image metadata (SBAT, AFAICS!)
>>2. using a single shim image build for all vendors
>>
>>It's not clear if **both** of these are expected to be used here or
>>not. Does SBAT depend on the single shim build? (I don't think
>>so?). SBAT looks sane enough, I think, but the single image build has
>>a multitude of possible issues for vendors. Probably OT to list all
>>the details here.
>
>We expect sbat to roll out soon. One-shim is a further out.
>
>I would expect that we'll see a one-shim for tools vendors that don't
>need specific feature sets before we see it for distros with more
>complex feature requirements.

Ok, that's fair enough.

>There are two hurdles for one shim that have not really been discussed:
>
> Some vendors may run into their own policies WRT redistributing
> binaries. (Although it may be possible to construe shim as a simple
> extension of firmware, which is "obviously not software" and is
> rarely subject to the same rules as software.)

*mumble* In Debian we're *really* not going to be happy shipping an
on-CPU program that we haven't built (can't build!)
ourselves. Firmware is already contentious enough. Pushing a major
trust anchor into binary-only / non-free territory would be a major
backward step, IMHO. :-( If this was actually built-in to the EFI
firmware on the hardware, that would be different.

...

>>(Maybe slightly OT) How does use of
>>EFI_VARIABLE_TIME_BASED_AUTHENTICATED_WRITE_ACCESS work? Does that
>>have problems on platforms without a working RTC? I'm assuming integer
>>rollover is checked for?
>
>It does not depend on the RTC, but uses the time stamp as an
>increasing counter.

OK. That's what I expected, just clarifying. :-)

>>Who's responsible for defining global generation numbers? I'm
>>guessing we'll need a central group to co-ordinate things here.
>
>Yes, we probably need to formally define this group. Initially at
>least I would expect this to fall on some of the same folks engaged
>in shim reviews.

ACK. Probably worth speliing out, I think.

>>#### Retiring Signed Releases
>>
>>If we start to ratchet up the minimum feature set (and generation
>>number) in various places, that's likely to break some end-user
>>systems if they take updates. Ditto for users with EoSL
>>installations. Is it worth considering an extra setting somehwere as a
>>half-way house for the user to say "I want some of the SB benefits,
>>but my stuff doesn't meet full current spec" ?
>
> That's not directly related to sbat, but we've discussed the fact
> that UEFI secure boot is very "all or nothing" and perhaps shouldn't
> be. Some way to allow someone to boot older, signed bits that may be
> vulnerable to certain CVEs without fully disabling secure boot would
> be nice. Perhaps with warnings on color coded console screens?

Cool, so it's not just me. :-)

>>#### Key Revocations
>>
>>How does generation numbering work for keys? Do we use a specific
>>per-vendor "Vendor Key" component added somewhere in the SBAT
>>variable. This is described briefly in the SBAT variable content
>>below, but should probably be explained in more detail.
> 
> Yes, we also need to define the file names for those key files.

ACK.

>>#### Version-Based Revocation Metadata
>>
>>Yay, you've explicitly added versioning on the SBAT metadata
>>structure! \o/
>>
>>The spec says UTF-8 for the .sbat section. Other stuff we do with PE
>>is all UCS-2 AFAIK, would we not be better to stay consistent here?
>
> There's been some back and forth on this. I'm not invested in a
> particular encoding as long as the data in the section as well as in
> the UEFI variable is encoded the same way.
>
> The argument for UTF-8 is that product names from multi-byte locales
> may well be coming soon.
>
> It would also allow me to add the face-palm emoji to to my own
> personal builds.

*grin* OK. I was more thinking of principle of least surprise: it
*will* confuse people to be using two different encodings here.

>>#### UEFI SBAT Variable content
>>
>>AIUI the proposal is to include information for *all* known
>>vendors/products/components in the SBAT variable. Even if most of the
>>generation numbers collapse back to the base, will that fit? Will it
>>fit in future? (AKA "how many vendors, products and components do we
>>expect?"). I certainly *hope* so, but I don't see any estimates for
>>sizes. Am I being too paranoid? :-)
>
> It's certainly going  to be smaller than repeat revocations of multiple shims per vendor.

Oh, absolutely. :-)

> But yes, most products will end up with a vendor key file. I'm
> hoping to use a single key file per vendor with all their keys for
> all their products to limit the number slightly.

ACK, that'll help. I appreciate I'm late to the discussion here
(argh!), but maybe could it work to move some of the product and
component details out into signed files? No, that's probably going too
far. Again, just trying to do the worst-case size exercise.

As you said, there's also a need to define how the vendor key files
work.

Oh, one more - is this all orthogonal to user-registered DB keys?
Again, I *think* so but that could/should probably be called out
explicitly.

Finally - I filed a PR with some copy-editing changes as well. I hope
it's useful - my OCD kicks in when I see this kind of document. :-)

-- 
Steve McIntyre, Cambridge, UK.                                steve at einval.com
"War does not determine who is right - only who is left."
   -- Bertrand Russell