[coreboot] Binary blobs in the source tree

Patrick Georgi patrick at georgi-clan.de
Tue Apr 17 18:12:41 CEST 2012

Am 17.04.2012 01:48, schrieb xdrudis:
> In the past I've bought hardware believing it was likely to work with
> free firmware by looking at what coreboot supports.
We already have some notebooks in the tree that require embedded
controller firmware that you can't replace - it's not just an
inconvenience that can be fixed by using the right
DRM/GEM/Gallium/DDI/whatever driver, but their absense actually breaks
the boot process.

Sorry, this was simply a wrong assumption, and for a long time.

> otherwise, it will be like what linux has become, you no longer know
> much by the statement that linux runs on something.
coreboot is not a free software certification process. Never was.

> It is pervasive, it has a big growth, it has many users. Yet it
> doesn't give them quite enough freedom.
What does that tell us?

> Coreboot may choose to go that route or may try to go the way of many
> other free software projects (GCC, Apache, debian...)
Apache is hardly a free software project (it's open source - the Android
"issue" you lament exists for a large part because they use the _Apache_

>> So the big question is really do we allow chipset support that 
>> requires the use of binary blobs in coreboot.
> I don't. I try to find chipsets that don't require that.
Then current Intel chipsets aren't for you: Sandybridge requires
(besides the MRC binary) a MEI binary, for the embedded controller in
the chipset.

Without a proper MEI firmware, the CPU won't even start executing x86
opcodes. The MEI firmware is signed (with some private Intel key).
You (or someone) might be able to reimplement the raminit part. Good
luck cracking the key to MEI firmware signatures.

It gets better: Intel TXT (some security feature) uses another signed
bit of code. This time for x86 (yes, ran on the CPU. Look up Invisible
Things Labs, they explain why this is a stupid idea even without regard
for any notion of "freedom"). Again signed with some private Intel key.
You can argue that TXT doesn't matter for you, but then why buy it (and
support a company producing such things)?

There's another vendor, a bit smaller, but with slightly more sensible
design decisions, that might suit your needs better.

> I don't think such a limited port is worth people's efforts, but 
> that's for each one to decide, of course. There are other propietary 
> BIOSes around for that hardware, a free port to any hardware is 
> worthwhile, a greenwashed half baked port of something that used to 
> be free is not a big deal.
Sandybridge support was never "free" (it wasn't there in the first
place), and I doubt that the intention was "greenwashing".

> and the propietary BIOS you got preinstalled from factory does the 
> job,
coreboot _is_ the firmware preinstalled from factory on those boards. I
truly hope it does the job.

> coreboot users have usually assumed they had permission to distribute
> the tree freely under GPL, not necessarily sending people to a single
> repository because the parties with distribution rights have
> designated it as distribution means.  I mean people can publish their
> git trees anywhere, can't they? Must they now prune the blobs or ask
> intel for permission ?
That's why we discussed moving the file into a separate repository,
"just to be sure" (and avoid annoying discussions about the DFSG down
the road).

> Others can claim coreboot compatibility
That first has to be desirable to vendors before I care.

> I guess it's better to just stop buying hardware, if you can't even 
> rely on a FSF priority project to get free software.
coreboot is no FSF project. Any such labelling is on their part. Sorry
if they misled you.

> Conformism with blobs seems to be so pervasive...
While mrc.bin matches pretty much every definition of the term "blob",
the FSF muddying the waters wasn't exactly helpful to keep that term


More information about the coreboot mailing list