The Mission Of Coreboot - Is It About Open-Source Or Appeasing Hardware Vendors?

[madscientist159]

If you're upset about vendors claiming coreboot functionality when it's *all* blobs, update the ugly-as-hell compatibility matrix to show it and design level qualities/endorsements that illustrate it. For example, bronze only boots with blobs. Silver only has blobs for non-essential pieces. Gold has no blobs. Platinum has no ME/PSP, or allows for it to be disabled.

I'd brought that up before, actually. Never gained any traction, and the current mailing list discussion is showing coreboot having strong objections to any prominent, publicly consumable information that might highlight the x86 blob situation.

What's the benefit to having a coreboot image that's all blobs? Anyone who hasn't lived under a rock for the past two decades has seen motherboards with the same chipsets offering different functionality and having different bugs. Having 5 bronze-level coreboot images based on the same chipset would allow people to grab different blobs from other vendors in case one vendor drops support early. It would also allow for multiple vendors and users to collaborate on replacing the same binary blob without having the exact same revision of the board from the same vendor.

Yes, vendors might take advantage when we allow binary blobs, but lots of issues arise in firmware that lie outside the binary blobs. Like hardware block lists, bad timings, incorrect ACPI tables, incorrect RDRAND settings, sloppy secure boot implementations, etc. Having a partial base to build and collaborate upon is much better than not recognizing community efforts *at all*. And it lets us add additional value in optional packages beyond the basics to multiple boards.

Almost everything you list above has historically moved into the blobs you are allowing. ACPI tables? BinaryPI. Whitelists? BinaryPI, FSP, etc. Secure boot? Dependent on those blobs to do the right thing in the secure boot chain. Timings? Maybe, but coreboot doesn't really have a nice interface or way to override timings aside from editing the source right now, and there's always the possibility the vendor decides to enforce whitelists or upper/lower bounds to the externally-provided timing data -- or simply enforces "select timings from this blob-generated indexed list".

Point is, all the reasons you have for allowing the blobs (excluding possibly the mix+match one) are relying on the blobs behaving they way you want, and there is no reason whatsoever to think you can do any of what you want -- perhaps not even mix+match if a small whitelist is included in each blob.

I just want to see the actual status of coreboot on x86 advertised vs. a pie-in-the-sky unattainable goal presented as current fact. If that real world status is chained blobs, just advertise it -- no problems with a little open source in the sauce as long as its actually stated as such.

[pgeorgi]

I'd brought that up before, actually. Never gained any traction, and the current mailing list discussion is showing coreboot having strong objections to any prominent, publicly consumable information that might highlight the x86 blob situation.

That's the least charitable interpretation of the discussion that I can imagine. You're interested in highlighting how horrible the situation is (see below) while we're trying to highlight the goal of the project.

Something that provides per-board information in something like board-status is very different from the requests to change the prominently placed 2-sentence marketing copy so that it no longer talks about the project but about its external constraints.

Almost everything you list above has historically moved into the blobs you are allowing.

I disagree:

ACPI tables? BinaryPI.

Most of ACPI still comes from coreboot.

Whitelists? BinaryPI, FSP, etc.

I understood Terrablit to refer to stuff like Lenovo's Wifi adapter whitelist, and those definitely aren't part of BinaryPI or FSP. What kind of whitelist are you thinking of, because I'm not aware of any in either binary.

Secure boot? Dependent on those blobs to do the right thing in the secure boot chain.

I understood Terrablit to be able to control things in the presence of Secure Boot: that is, the freedom to still do whatever you want here. Apart from that: is "write32(a, b);" undermining security? Can't tell without knowing all side effects of a and b. That is: open source is a necessary but not a sufficient condition for the level of assurance you seem to be thinking of.

Timings? Maybe, but coreboot doesn't really have a nice interface or way to override timings aside from editing the source right now,

That's shifting goal posts: Isn't open source enough anymore?
Also, where's the nice 3D-accelerated graphics user interface to edit timings for TALOS?

and there's always the possibility the vendor decides to enforce whitelists or upper/lower bounds to the externally-provided timing data -- or simply enforces "select timings from this blob-generated indexed list".

And this is devolving into hypotheticals.

I just want to see the actual status of coreboot on x86 advertised vs. a pie-in-the-sky unattainable goal presented as current fact. If that real world status is chained blobs, just advertise it -- no problems with a little open source in the sauce as long as its actually stated as such.

So you're on a mission, "", understood. I would help though if you'd be able to stick to facts before asking others to do so.

[madscientist159]

That's the least charitable interpretation of the discussion that I can imagine. You're interested in highlighting how horrible the situation is (see below) while we're trying to highlight the goal of the project.

Something that provides per-board information in something like board-status is very different from the requests to change the prominently placed 2-sentence marketing copy so that it no longer talks about the project but about its external constraints.

I understood Terrablit to refer to stuff like Lenovo's Wifi adapter whitelist, and those definitely aren't part of BinaryPI or FSP. What kind of whitelist are you thinking of, because I'm not aware of any in either binary.

I understood the whitelist comment to be more related to AMD's recent disabling of Gen 4 capability on specific boards. Either way it's hard to argue functionality like a whitelist wouldn't be moved into vendor blob(s) over time.

I understood Terrablit to be able to control things in the presence of Secure Boot: that is, the freedom to still do whatever you want here. Apart from that: is "write32(a, b);" undermining security? Can't tell without knowing all side effects of a and b. That is: open source is a necessary but not a sufficient condition for the level of assurance you seem to be thinking of.

I think we agree here. That's why a recent addition to our overall open systems criteria is release of enough hardware documentation to understand what is happening. AMD used to do this in the Bulldozer days, IBM does this now, ARM SoCs generally have had this available for the past several years at minimum. As far as I know AMD still provides a significant amount of this documentation but has locked away the PSP documentation and related material behind a strong NDA, similar to how Intel unfortunately treats some of its documentation.

That's shifting goal posts: Isn't open source enough anymore?
Also, where's the nice 3D-accelerated graphics user interface to edit timings for TALOS?

I'll grant you the shifting goalposts here, I just wanted to highlight how this particular feature doesn't seem to be something that anyone using coreboot is really doing (yet?), even though it was brought up as a possible real-world reason to prefer coreboot as glue between binary blobs vs. a closed solution.

And this is devolving into hypotheticals.

Aren't the project goal statements on the coreboot Web site hypotheticals though? If we agree to stay away from hypotheticals, that means coreboot should also stay away from hypotheticals about Intel/AMD finally opening up their entire firmware stack, unlocking the ME/PSP, and releasing full documentation on all of the hardware internals.

In particular these statements are rather difficult to read as anything other than hypothetical (and IMO unattainable) goals:

As an Open Source project it provides auditability and maximum control over technology.

As a native English speaker this is not clear that "maximum control" means "maximum possible control within vendor-imposed hard limits". In fact it sounds like if I use coreboot I get complete and full control of the hardware I'm using coreboot on.

Uses a minimal trusted computing base for each platform which is easily auditable, helping to guarantee security.

These are weasel words given the required blobs. What exactly is the "minimal trusted computing base" in light of the ME and FSP for Intel?

After it has completed initialization, more than 99% of the code is removed from memory.

Even the small ME is 1.5MB. Unless your coreboot image is ~150MB, this is by definition false.

In general because it [coreboot] leads to freedom on machines. Most firmware written today is completely closed source and the code bases are growing. Years ago a computer needed 100kb of compiled code in order to run the southbridge, now around 8mb of code are shipped in modern hardware.

This is highly misleading. It sounds like coreboot is presented as a diametric opposite to "Most firmware written today is completely closed source", when in fact it's largely more of the same closed source bits strung together with open code. Again, making sure to avoid hypotheticals regarding theoretical opening of more code.

neutralized Intel Management Engine.

Isn't this something like saying a dirty polluting car is "neutralized" because it's only driven a smaller distance than before and given a minimal exhaust filter, but still driven every single day? "Neutralize" is defined in English as "Make (something) ineffective by applying an opposite force or effect." -- since the ME must run to initialize the platform, I can logically conclude that any "neutralization" is at least partly ineffective since the platform still boots.

[Terrablit]

I understood Terrablit to refer to stuff like Lenovo's Wifi adapter whitelist, and those definitely aren't part of BinaryPI or FSP. What kind of whitelist are you thinking of, because I'm not aware of any in either binary.

I understood the whitelist comment to be more related to AMD's recent disabling of Gen 4 capability on specific boards. Either way it's hard to argue functionality like a whitelist wouldn't be moved into vendor blob(s) over time.

Pgeorgi is correct. The comment about blocklists was explicitly around OEM vendors disabling hardware that's not in pre-approved lists maintained in the firmware, which was (and may still be) an extremely common OEM practice with laptops. Dell, Lenovo, HP, etc - all of them had models at one point in time that prevented booting with unrecognized hardware. I've got one from 2008 that does this. Some desktops did it, too.

This type of functionality usually isn't inside the blobs that are tied to the chipset and CPU. They're usually compiled tables or EFI/BIOS modules, but they're a lot easier to find than those, and can usually be removed without much issue. Drop the table or module, remove the reference that called it during initialization. Vendors could be smart about it and hide it in unrelated code, but they can't hide it in microcode blobs and stuff like that where Intel/AMD don't give them the source.

BIOS modding communities used to do this sort of thing, as well as other things like enabling Virtualization support options that weren't displayed in vendor firmware (as was common on Sony VAIO laptops when VT-x/VT-d was new) or removing vendor limitations (like when some laptops limited the SATA ports to a lower speed than the hardware supports), or fixing bad ACPI tables that were ignored in Windows but broke Linux. Sloppy vendor "customizations" cause no end of grief to Linux.

Having an open-source firmware framework that loads blobs means you can work around issues from the motherboard vendors - ASRock, MSI, Lenovo, Asus, etc - a lot easier. The necessary blobs are related to the chipset and CPU, and most of that is exactly the same for the same chipset. We have far more functionality problems from the motherboard vendors than we do from the CPU vendors. We can lean on the CPU vendors directly to have a way to disable security co-processors. And we have to do that anyway. Motherboard vendors just don't care if things are broken.

And, as stated, if we can support chipsets, that'll add preliminary support for multiple boards that use them, and make collaboration easier on reverse engineering the blobs. Some hardware is even shared across chipsets.

As a native English speaker this is not clear that "maximum control" means "maximum possible control within vendor-imposed hard limits". In fact it sounds like if I use coreboot I get complete and full control of the hardware I'm using coreboot on.

EDIT: Do you think that "maximum control" will turn you into a God when you install Coreboot? Will it grant you the power to create and destroy worlds, to dominate the markets and turn lead to gold? Will it let you store the number 257 in a byte? No. There's always an implied limit. It's up to the reader to figure out what the maximum is, and not start a cult around unfettered "maximum control." You wouldn't even know you're not getting "maximum control" until you read enough to understand why you can't get it.

Literally no one with any background knowledge has had this expectation since motherboard BIOSes became flashable and CPUs started having microcode patches. It might have passed the halfway point of the x86 platform. Meaning it's been this way most of the time x86 has been dominant. And x86 has set the expectations, so there's no need to be pointing out x86's "unique situation". Because it's the situation of 90% of available computing hardware. Fully FOSS booting is just gaining momentum withthe new focus on security, and it's not anyone's expectation who knows anything when they look up random hardware.

Coreboot isn't marketed to grandpas, toddlers and basket weavers. If you're looking into BIOS replacement in the first place, you should understand the underlying technologies. The information is on the Coreboot pages, just not front and center. If you flash your motherboard to Coreboot without RTFMing, you deserve any and all problems you get.

Domain terminology overrides native English expectations. Computers and firmware have words and phrases specific to them. No one reasonable sets their viewpoint on a product based on the frontpage blurb. If you don't get the background information to understand the product, you shouldn't be the decider. Otherwise we'd have to fill the frontpage with idiot caveats telling people to not swallow coreboot, and that coreboot is not intended for anyone under 12 years of age, and that coreboot might eat your babies.

Coreboot has had the same goals and same mission for two decades, now. Just because vendors get in the way of the ideal implementation doesn't mean we need to get on their asses about how it's "false advertising".

[aaahaaap]

Coreboot has had the same goals and same mission for two decades, now. Just because vendors get in the way of the ideal implementation doesn't mean we need to get on their asses about how it's "false advertising".

Why not? It is false advertising.
Hopefully it triggers the coreboot devs to go back to the original goals and reject/remove things that are in conflict with it or move those into a separate project.
If not at the very least the honest thing to do would be to update the description.

[Th3Fanbus]

So, since Timothy Pearson (also known as madscientist159) works at Raptor, let's take a look at the Talos II: https://wiki.raptorcs.com/w/images/4...00_non-sas.png

Besides the "non-sas" name, which implies there's a version with a SAS controller (usually not very open things), let's look at the networking department... Oh, BCM5719? Ah, Broadcom, just like the Raspberry Pi. No datasheet to be found, product briefs show up instead. I did not look much around because missing datasheets is usual with Broadcom. Well, at least there should be open-source drivers?

There's the "bcm5700" driver from Broadcom, which seems to have some "binary code" for TCP/IP stack offloading and TCP segmentation... Where would that binary be? The tg3 driver also looks odd... WHAT? Please check https://github.com/torvalds/linux/bl...com/tg3.c#L220 immediately. Binary firmware? Moreover, line 1745 mentions "firmware" and "magic" on the same line. How does this fit with the "Trusted Security" advertised here? https://www.raptorcs.com/TALOSII/

Enough, let's look at the BMC. AST2500. No datasheet available. How does graphics init happen, then? Let's check... Nice, https://wiki.raptorcs.com/wiki/Troubleshooting/GPU says it doesn't, unless you add "firmware" (no openness status indicated, but it's likely just a regular video BIOS). Awesome, so no video without blobs. Because Nvidia is Nvidia, and AMD/ATI has AtomBIOS... So we're headless on the Talos II without blobs, folks!

Plus, there's a NC-SI link between the AST2500 and the BCM5719. Nice, the BMC has sideband networking capabilities. Great to know, given that unfixable hardware flaws exist: https://github.com/openbmc/openbmc/issues/3475

Let's move on before I faint. Between the socketed SOIC-16 chips and the RTC battery, there's a weird chip... Does it say Lattice? It doesn't appear in the block diagram, but it's probably a CPLD of sorts. It's likely just glue logic, but who knows? I don't know if there's sources for its bitcode, but even if there are, there's likely no open-source toolchain for it. Since the schematics are not available unless one purchases a mainboard, I can't see what it is supposed to be.

Without the SAS controller, does this board have any SATA ports? Um... Nope. How does the Blu-Ray optical drive in https://raptorcs.com/content/TL2WK2/intro.html work, then? I see that the storage drive problem is addressed with NVMe, though. Note the recommendation on the Radeon Pro WX 7100 graphics card, which is heavily reliant on firmware.

So, in short, the POWER things might be nice and everything. I did not read any source code, but I know the public documentation is thinner than Intel's or AMD's, which makes me wonder how much one can change the source code without having to guess. It also reminds me of AMD's AGESA, which is rotting in coreboot's tree alongside the older AMD server boards Raptor used before.

OTOH, there's things which are not-so-nice on the Talos II world, which I don't think were brought up before. Knowing about them, I strongly believe that the drama caused in coreboot's mailing list was just done for marketing purposes, since most people stick with coreboot and x86.

Any comments?

[pgeorgi]

Why not? It is false advertising.

That's _one_ opinion (and that difference in opinion is the source of contention here). Since coreboot leadership disagrees and they're ultimately the ones deciding what changes are made to the frontpage, screaming louder won't change a things - except...

If not at the very least the honest thing to do would be to update the description.

The conduct shown in this debate isn't conductive for promoting change. If anything, the way this demand was brought up only ensures that nothing will change.

For people trying to shape the politics of software freedom, politics certainly isn't the strong point of many of the folks involved.

Hopefully it triggers the coreboot devs to go back to the original goals and reject/remove things that are in conflict with it or move those into a separate project.

We could have done that in the 2009 time frame. The result would have been that in 2019 (as in: now) there would have been 0 lines of open source code that are actually usable by folks. Tianocore would probably exist like it does now, but with no chance for device owners to actually customize it on their device.

There are lots of dealings with hardware vendors behind the scenes, and it's a constant struggle. We're now in a position that silicon vendors are trying to work within the open source firmware environment, a notable change over the last 10 years. From here, we can (and do) put pressure on vendors to open up more parts, while there's usually back pressure to close down more (that we have to push back against).

This kind of conversation (and struggle) will end the moment we stop working with them at all "until our demands are met": they won't be met, and they have hardware to sell. Instead, silicon vendors will immediately go back to the scheme they know: send blobs (and sometimes sources) to IBVs who sell shitty code + services to clean it up to OEMs, and a "security model" that's based on "if nobody can modify it, the device is secure".

However, what these kind of discussion does is: you spend a minute on presenting your case (like dozens other folks: I haven't seen a single new argument on the "firmware freedom" topic in the last 5 years). Each of these minutes cost: 1 minute to engage with you. 1 more minute to deal with silicon vendors engineers (who are usually sympathetic to open source firmware but aren't the ones who decide product direction) who complain (sometimes appropriately) about the hostility in the community. 1 more minute to deal with interested devs who are put off by the bickering (twice, because the dev is also not contributing to a better firmware situation, but considering their options). And finally 3-5 minutes to keep the various factions from warring each other: The question what constitutes an objectionable blob isn't answered the same way by various people. The People's Front of Firmware Freedom sometimes seems even more discontent with the Firmware Freedom People's Front than with the blob-shipping silicon vendor (and vice-versa).

So, present your case. But also consider please if your contribution is actually original or if it merely reiterates some ancient point, where every minute of you writing something wastes some 8 minutes that could be better spent lobbying silicon vendors to do better.

[schmidtbag]

Cool! Lets say I've got a set top box here that uses 10 lines of coreboot to load a DRM enforcing OS. The megabytes of vendor firmware before it, and the gigabyte of vendor binaries after it, are signed, locked, and encrypted. I can look at those 10 lines of code, but not touch.

Would you choose this set top box over a cheaper, fully proprietary model just because of those 10 lines of open source?

Yes, because I'm not a Stallmanite and 99% of the media I'd be consuming on the set top box doesn't comply with open-source standards anyway.
So riddle me this:
Is it really Coreboot anymore if you're using that little of it?

Have you actually looked at the ratio of open code to vendor binaries in coreboot for modern platforms, including the ME/PSP and microcode?

Have you? Because even taking into account you're exaggerating, 10 lines of code for a crucial platform like Coreboot isn't going to do anything.

[starshipeleven]

Have you? Because even taking into account you're exaggerating, 10 lines of code for a crucial platform like Coreboot isn't going to do anything.

Yes that's his point.

On Intel platforms the blobs (the FSP) are smart enough to init the whole thing and are also able to load payloads (like say u-boot) on their own. Coreboot is basically a wrapper for that. Also the docs to configure the FSP are available only under NDA.

On most modern AMD stuff you can't run shit with Coreboot because they don't release the AGESA (and documentation) for them.

Is it really Coreboot anymore if you're using that little of it?

That's more or less what the article is about. The Coreboot website still states the original project goals which are far from the actual reality.
Nowadays Coreboot is more or less a wrapper for the FSP, what you can do on it without an NDA with Intel is limited because of FSP blobs and their (lack of) documentation, and on top of that it's not used much outside of x86.

So is Coreboot really Coreboot anymore?

[schmidtbag]

Yes that's his point.

His point is having a dysfunctional amount of Coreboot code is enough to qualify as using Coreboot?
Even still - so what? If a product is advertised as "Coreboot ready" but nothing worth mentioning is actually made from Coreboot, then that's false advertising and you get to sue. If you were hoping it used Coreboot for the sake of modifying it for your needs, well, you should've done more research. If you don't intend to even look at the source code, you won't know the difference, so if the product works as expected, why does it matter how little of it is actually Coreboot?
If it's all about sticking to principles, well, good luck with that.

That's more or less what the article is about. The Coreboot website still states the original project goals which are far from the actual reality.
Nowadays Coreboot is more or less a wrapper for the FSP, what you can do on it without an NDA with Intel is limited because of FSP blobs and their (lack of) documentation, and on top of that it's not used much outside of x86.

So is Coreboot really Coreboot anymore?

Yes, Coreboot really is Coreboot. Just because the way it is used doesn't conform to Coreboot's goals, doesn't mean the software suddenly lost sight of its goals. I really don't understand how this is up for debate. Cotton swabs do not exist to clean your ears (in fact, on the box it explicitly says not to do that), yet, that's easily the most common use of them. So, does that mean products like Q-tips need to rebrand themselves as "ear canal cleaners"?

The difference here is Coreboot is open-source. One of the key benefits to open-sourcing something is so you can modify it to your needs. For people who whine about an open-source tool being mutilated for proprietary needs is ridiculous. That's like giving an angsty teenager a can of spray paint and putting him in front of a brick wall with no surveillance and getting upset that he vandalized it.

As the saying goes, "this is why we can't have nice things".