[coreboot] To bin or not to bin. was: Allow components to add files to CBFS

[xdrudis]

On Wed, Dec 15, 2010 at 10:07:50PM +0100, Patrick Georgi wrote:
> 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:

I don't quite dislike "blob", but any meaningful alternative would do
for the warning. I'm not sure the name of the file alone would do, 
some sort of taint flag, or license info would be ideal.
In fact the best I can dream of is the name of each file, the license and the availability 
of source (linux has parts nominally under GPL without source code).

But of course source code would need a definition. I seem to
intuitionally feel I know it (the GPL definition), but then I find
cases of people disagreeing, and they may not all be in bad faith.

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

I don't care where it runs. For me it's more whether it's been derived from
some other form and what's more useful to touch if you want to change it.
There's also the question of whether it can be replaced, but if it couldn't
it wouldn't be included, of course.
 
> <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 don't get your rant. Whether there is source or not does not depend always
on the format. If your bootsplash was made with gimp it would be
better to include the source (it would be easier to combine with the
logo of the hardware owner company, for instance, or adapt to other
resolutions...), if it was made with a camera, maybe it's not so
necessary to include the raw image and settings. 

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

I think the discussion may have been less interesting to you than to them
because you knew the algorithm better, but I think it was a relevant question.
For me it would give insight on "where the security comes from" if I had
time to learn AES. Must be similar to DES. I've never understood what
makes those permutations secure or others less secure.

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

I hope it does not change even if one day vendors start giving permission
to distribute sourceless binaries, as happens in linux or elsewhere.
In fact there's already CPU microcode, but I'm not sure what would be
"source" for that, so it may be ok.
 
> (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)
>

Ok. I'm happy to avoid that debate until the choice comes. For me 
it's enough now to know there won't be binaries in the tree so users
will have to opt in. I tried to change the subject header because
it's no longer about the patch.
 
> The other fact: Hardware relies more and more on update-able components in 
> flash, without any knowledge of what this is.

And that drove me to coreboot. This is why the project would lose all interest
for me if this market trend would be accepted as an excuse for including
sourceless stuff. But I guess that the project wouldn't lose much from
my loss of interest in it.

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

I'm not arguing the usefulness of hardware without binary stuff in
those cases, I'm just arguing the usefulness of free firmware lacking
source for components that do have source but it is not public.
 

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

That brick would at least be useful to develop free replacements for the 
missing parts :) 

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

Default ? or policy ?

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

Thanks for explainig. Yet build system magic may hide important info
from the user _if_ binaries are distributed. So as long as they are
not, I'm 80 % happy with it (sorry, an old joke from the swpat EU
directive).  Still helping users install non free software is not nice
(as stated in the GNU free system distribution guidelines, for
example), although I'd say coreboot users are not so naive as not to
notice. Coreboot is not exactly as easy to install as Ubuntu.