[coreboot] FSP 2.0 headers in coreboot

Nico Huber nico.h at gmx.de
Sat May 5 13:36:38 CEST 2018


On 04.05.2018 23:41, Aaron Durbin via coreboot wrote:
> On Fri, May 4, 2018 at 3:20 PM, Youness Alaoui
> <kakaroto at kakaroto.homelinux.net> wrote:
>> Hi,
>>
>> I've just pushed a commit for review on gerrit
>> (https://review.coreboot.org/#/c/coreboot/+/26108/) and I'm hoping to
>> open the discussion here on whether the public coreboot code should
>> have the FSP headers that match the public FSP headers or if they
>> should match the 'google fsp' headers.

I tried myself before [1] and ran against a wall of lies and broken
promises.

Roughly:

  - July to September/October: I warned Intel about the situation
    over all available channels (Gerrit, different corporate support
    channels, wrote to Vincent who uploaded the first Kabylake FSP
    to GitHub, several laments about the situation on this mailing
    list I guess).
  - After the first Kaby Lake FSP drop on GitHub, Intel commented
    on Gerrit that the headers there are outdated and internal ones
    have to be used.
  - December 11th, Intel commented on Gerrit that everything is sorted
    out.
  - December 13th, Intel painted Kabylake FSP "Gold" with 6 months
    outdated UPDs.

>>
>> My understanding of the situation is that chromebooks ship with a
>> google-modified FSP image and the fsp headers in coreboot have been
>> added by google employees even before the FSP was officially made
>> public by Intel. I also somewhat understood that the fsp headers in
>> coreboot would not be updated to match the public release because it
>> would break everyone building coreboot for their chromebooks or
>> something like that.
> 
> They aren't modified necessarily. It's more of different views on the
> same timeline of a development. Granted, the releases are definitely
> not coordinated. I'm not even sure how/who releases the github
> blobs/headers on Intel's side.

I have more a feeling that different branches exist.

> 
>>
>> I'm a bit tired of always having that commit that fixes the header
>> applied locally in all my branches, and I think that it makes much
>> more sense for coreboot to have the fsp headers that match the public
>> release and for the google/chromebook coreboot repository to have the
>> "non-standard header" committed to it instead.
>> Worst case scenario, we could add #ifdefs to determine what the
>> structure contents should be depending on the target platform.
>>
>> Maybe everyone will say "of course, that makes sense" or maybe
>> everyone will say "nope, I disagree", but hopefully we can have the
>> discussion here (or on gerrit) and decide how to handle this use case.
>> Note: I only pushed for skylake/kabylake, but apollolake/canonlake are
>> probably also affected by this mismatch of headers.
> 
> I think we should have both that can be selected through a Kconfig
> such that we can bind to the headers correctly. We already had to do
> that for edk2 issues as well. I can't think of better alternative at
> the moment that supports both.

You can not just switch headers. As Youness pointed out in his commit,
UPDs used by coreboot are missing in the public release. We'd clutter
up the tree with #ifdefs. And once that started, I'm sure, somebody
will use that as excuse to practice it further. OTOH, we could just
revert the past 10 months of soc/intel/. The major stakeholders had been
warned early enough. If somebody gets that through Jenkins, I'll +2.

Um, a little more serious: I believe the only solution is to enforce
some sane rules about code changes that depend on blob headers and
blobbed platforms in general, e.g. (just a draft; but I wouldn't mind
if we take it verbatim):

(meaning of *shall*, *should* and *recommended* as specified in [2],
"changes" refer to new commits for the coreboot master branch)

   0. Generally:
     All platforms should be blob-free.

     All blobs should be redistributable.

     Providers of blobs should sign them and take responsibility
     that the signed blobs were unaltered after compilation (e.g.
     do not contain malware). It is *recommended* that the public
     key needed to verify the signature is obtainable through a
     specific channel (e.g. single responsible contact person)
     _independently_ from the blob's distribution path.

  1. After the coreboot 4.8 release:
     All changes to a binary-specific header file (including
     the addition of new files) *shall* be refused, unless a
     matching binary is publicly available.

     For each platform that relies on a blob, the coreboot tree
     *should* point (e.g. git submodule) to a commit containing
     both the header files and the matching binary.

  2. After the coreboot 4.9 release:
     For each platform that relies on a blob, the coreboot tree
     *shall* point (e.g. git submodule) to a commit containing
     both the header files and the matching binary. If the plat-
     form code within coreboot supports multiple variants of that
     platform, that commit shall contain all necessary binaries
     for all variants supported by coreboot, all compatible with
     the same header files.

     Unless a pointer as described above exists for a given plat-
     form that relies on a blob, all changes* to that platform
     *shall* be refused.

     All platforms that rely on a blob that is not redistribu-
     table and whose distribution as an individual file has been
     stopped or has never happened *shall* be immediately removed
     from the master branch.

     *excluding changes to maintain tree-wide compatibility

  3. After the coreboot 4.10 release:
     Unless a pointer as described above exists for a given plat-
     form that relies on a blob, that platform *shall* be imme-
     diately removed from the master branch.

     Unless a signature as described above exists for a given
     blob, all changes* to platforms that have been launched to
     market and rely on that blob *shall* be refused.

This should give everybody enough time to adapt and the refusal to
merge new patches should constantly remind them so they won't
forget the matter and panic right before a release.

One reason for not writing this up earlier is that it potentially
hits a lot of CrOS devices. Though, in the proposed scheme there'd
still be 6 months for Google to figure things out.

Nico

[1] https://review.coreboot.org/#/c/coreboot/+/20477/
[2] http://www.ietf.org/rfc/rfc2119.txt



More information about the coreboot mailing list