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

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

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

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.

[Terrablit]

I really hate these purist arguments that throw shade on companies that pragmatically offer partial support. It helps gain traction and provides suitable entrypoints for contributions. And the people who crusade on this nonsense waste massive amounts of community time, as well as damaging community efforts from their inability to recognize any subtlety at all.

No x86 vendors submit full code to booting on modern systems. And open-source shouldn't mandate using decade-old hardware. It reduces marketshare and provides an artificial barrier to entry for people that has no need to exist. Nearly everyone who went FOSS had partially-closed hardware at some point in time, so they need to get off their purist high horses and recognize that ease of entry brings visibility and contributions that the project sorely needs.

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.

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.

And honestly, having LibreBoot as a separate project was always stupid. Compatibility matrices should have been adjusted to show functionality with/without binary blobs, and build scripts should have made blob inclusion optional. Having it be a separate project designed to collect FOSS brownie points for adding patches to remove functionality was a colossal waste of effort and prevented people from working on the same team to maximize availability. Not to mention the massive shitshow of mental instability we get from FOSS purists running the show. Remember when the head of Libreboot decided to attack GNU and drop out entirely on her own? That was a massive waste of time and energy.

Now that I've pointed out how having partial support actually helps the community and the consumers, take a moment to consider if you're willing to collaborate with people who can compromise. If not, please kindly fuck off with your attempts to force everyone else to do things your way or face a shame tax. Go bother the people in Libreboot. We've already made community space for one weird purist asshole (RMS) to remind us of the goals. We don't really need more. But you're welcome to challenge him for his position with a trial by combat. Go steal his conch if you need to be heard that much.

[bachchain]

If this was just about that small group that flashes their firmware, you would be right. But I think this has more to do with educating the less technically advanced who may never alter their existing firmware but may make decisions about what to manufacture, what to stock, and what to buy. Given the choice, I would prefer to buy boards that already supportencoreboot and/or libreboot.

we're talking about a two sentence product summary. I fear for the future of any company or person that bases any decision solely on that.

[madscientist159]

Given the choice, I would prefer to buy boards that already supportencoreboot and/or libreboot.

This whole discussion though is about coreboot not really standing for open source per se; right now it's mainly a shim loader / open framework around ME/PSP/FSP/AGESA/BinaryPI/etc. Libreboot is probably a more tangible indicator of open source support, plus there are a couple of other projects that also basically mean fully open now (the IBM POWER stack, oreboot, etc.)

[chithanh]

I agree that being an open source project and shipping the FSP blob is mutually exclusive. Coreboot should either stop shipping the FSP or stop calling themselves open source and auditable.

The wording could be changed to the following to make it honest: It aims to bring more Open Source to the boot process, it providing better auditability and increased control over technology.

The situation around the openness of Coreboot becomes clouded with some vendors like Purism prominently advertising their "open-source" Coreboot support but without mentioning that FSP binaries for example are still being used

That however is not a Coreboot problem. That is a Purism problem, this company routinely overstates their capabilities in this regard.

[marsbase]

Who cares? Any user that goes out of their way to replace their motherboard firmware is going to understand the limitations regardless.

If this was just about that small group that flashes their firmware, you would be right. But I think this has more to do with educating the less technically advanced who may never alter their existing firmware but may make decisions about what to manufacture, what to stock, and what to buy. Given the choice, I would prefer to buy boards that already supportencoreboot and/or libreboot.

[madscientist159]

... what's preferable is me_cleaner. Letting Intel and the vendors maintain their hold on our hardware by allowing them to put firmwares in the kernel and coreboot is not something that we should support on the PC.

This is non-sequitor as written. Did you mean to say something else, or do you not understand that me_cleaner leaves the (mandatory) ME as part of the boot flow? *

* unless you're referring to a Core 2 era system, but those are a decade old now.

[madscientist159]

Who cares? Any user that goes out of their way to replace their motherboard firmware is going to understand the limitations regardless.

Then what's the harm of being transparent on the home page? This type of thing is fundamentally why the nutrition facts ended up being mandated, precisely because the vendors advertised tasty but unhealthy food (great analogy, BTW!)