SBAT feedback

[Jan Setje-Eilers]

> [ Adding a CC to Jan as requested ]

 Thank you!




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

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

 There are a couple of different feature sets that have not been converged upstream, so it would need to be more like three or five shim if we wanted to roll this out soon.

 It would be nice to see vendors reduce the number of shims they require as much as possible. At least theoretically there's no reason a vendor would need more than one shim for all their products, but working for a large company myself, I understand that it may take time to get different orgs to consume the same binary.

>The whole thing is (mostly) orthogonal to existing vendor signing
>processes and keys. That looks like a good thing - we're just
>re-working how **revocation** works. We're still missing a good
>cross-vendor discussion on how to manage keys etc., but that's a topic
>for another day.
>
>#### Generation-Based Revocation Overview
>
>(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. 

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

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

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


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

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

 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.

 Thank you for your comments, I'll update the spec!

-jan