[coreboot] [PATCH]Allow components to add files to CBFS

[Patrick Georgi]

Am Mittwoch, 15. Dezember 2010, um 20:17:18 schrieb Xavi Drudis Ferran:
> If the later I don't like the idea and at least I would like  a huge
> warning "BLOBS IN HERE !!!" at the end of the make output.
I avoid the term "blob" for two reasons:
1. "BLOBS" (in this context) is an FSF scare term. Free and Open Source 
software had to endure FUD long enough, we should know better than to 
participate in that.
2. "blob", as used by the FSF, is not cleanly defined, and their use of that 
word or its predecessors changed over the years. It used to be that their main 
issue was with binary components that are run by the CPU, but now it  
encompasses much more.

I prefer the OpenBSD definition of "blob": binary components that run on the 
CPU. That a clear line drawn in the sand, and a useful distinction, too.
Unfortunately GNU/blob spoiled that.

<rant>
Applying the current FSF use of the word, a graphic rendered to png or jpeg 
without the source material (vector graphic, gimp image with multiple layers, 
...) shipped with it is a blob. We're lucky that we never added a default 
bootsplash image to the tree!

I had to debate with GNU developers if the S-Boxes in AES are "blobs", and if 
there's a "preferred format" for them (ie. if they could be calculated). They 
can't be calculated (there are a couple of formulas to verify if an S-Box is 
valid, but many are), but if you pick the wrong "valid" one, you get a 
different (and probably less safe) algorithm.
The FSF meaning of the term only scares the same people who use it that way.
</rant>

That there aren't any binary components in the tree is simply for the fact 
that they're not redistributable: We usually scrap them from vendor BIOSes, 
and they're not separately available.
That won't change.
(It would spark quite a debate when storing binaries in the tree would 
actually be proposed, but we never even got that far for the stated reason)

The other fact: Hardware relies more and more on update-able components in 
flash, without any knowledge of what this is.
Maybe it's 8051 code, maybe it's VHDL stuff of some sorts, maybe a table like 
the S-Boxes, or a JPEG image.
There is no preferred format, there's usually no disassembler for the data, or 
documentation that can be read outside the high security area at the vendor 
(and very likely only in 5pt print, orange glyphs on red paper in the area, to 
prevent anyone from making copies), but there's a single invariant for most of 
them: Without the data around, your system won't boot - it's useless as a 
brick, with the only feature that it sucks power.


For this reason, I'm thinking about adding a "thirdparty" directory, which 
contains only a script. That script contains a list of hash values and "real 
file names", and renames files within that directory which match a hash to the 
assigned filename.
The script would be a tool to simplify handling for users who have to scrape 
their binary parts from BIOS images:
Fetch the data, put it in the directory, run the script. If the data is known, 
it's automatically available for the board or chipset that needs it.

If you prefer to live without the file, simply don't put it in there. Your 
board might be less useful than a brick, but that's your choice.
The default will be to not ship those files, both because we aren't allowed to 
redistribute them, and to have a safe default from a license perspective.
It's also a safe default from an operation perspective, as the build will 
break by default (we might have to tweak the buildbot a bit to be tolerant of 
that, for example by seeding the thirdparty directory on the buildbot with 
empty files of the right names and sizes)


This patch won't change anything in this regard. The plan with the script I 
outlined is only where I see where this project is heading, for technical 
reasons.
What this patch does is eliminating a bottleneck: Right now we have to 
maintain a list of files that can be added to the CBFS image at a central 
location, and that won't scale in the future.
Nothing more, nothing less. No feature at coreboot runtime (or misfeature as 
you'd probably see it) is added or dropped, it's just build system magic.


Patrick