On 04.05.2018 23:41, Aaron Durbin via coreboot wrote:
On Fri, May 4, 2018 at 3:20 PM, Youness Alaoui kakaroto@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
On Sat, May 5, 2018 at 5:36 AM, Nico Huber nico.h@gmx.de wrote:
On 04.05.2018 23:41, Aaron Durbin via coreboot wrote:
On Fri, May 4, 2018 at 3:20 PM, Youness Alaoui kakaroto@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.
The technical challenges of managing different sets of headers doesn't seem too hard. Things can be isolated fairly easily w.r.t. to the field mismatches. Code can be co-located to handle such scenarios and keep it isolated.
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)
- 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.
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.
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
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.
It's just not Google who can sign up for such things. There are legal agreements about some of the points above that may make it completely infeasible to meet. As you pointed out there is 6 months, but contracts would have to be renegotiated.
I'm curious how you want things to play out from above. Could you provide how you think things will look over time? This isn't just impacting recent and new Intel platforms. There are other vendors beside Intel. I'm trying to understand what platforms would be supported in practice on coreboot.
Nico
[1] https://review.coreboot.org/#/c/coreboot/+/20477/ [2] http://www.ietf.org/rfc/rfc2119.txt
-
Aaron Durbin -
Nico Huber