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

[phoronix]

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

There was recently a debate on the Coreboot mailing list about the mission statement / description of this open-source BIOS/firmware replacement for systems that traditionally has liberated boards from proprietary BIOS but still on modern platforms is often pulling in a number of binary blobs...

http://www.phoronix.com/scan.php?pag...t-Mission-2019

[ms178]

The topic reminds me on the Simpson's lawyer who thought that the "Neverending story" was the most blatant case of false advertisement.

[ms178]

On the subject: The pragmatic approach would be to accept the realities of today and thrive for an open future. And the initiatives of Intel and AMD are heading into the right direction. It might still take a while and might not be completely open, but considering the past I'd say it is still progress.

[R41N3R]

Maybe they should just note that it is mostly an open source project or that they try to be as much open source as currently feasible. A clear communication which components are binary blobs is required from my point of view. If a normal user visits their website it is nearly impossible to find out what are the non open source components. I would love to replace UEFI with coreboot on all my systems, but not under a false flag advertisement :-)

[ezst036]

The big problem I have is that vendors sometimes only provide a "support window" for a few years, kind of similarly to how it used to be with graphics drivers and other drivers.

But now, with graphics drivers being(so often times) open source, we still see new updates to R600s/r300s and even Rage 128s from time to time, and this can only happen if the source is open. These are higher profile examples and I'm sure other devices similarly see longer support than would otherwise normally be available in the strictly corporate-controlled past. It used to be that when they wanted to cut you off, you were then cut off and that was it.

This issue is compounded if a vendor goes out of business because that can have an affect on devices currently within the "support window". We are a long time away from when Abit went out of business so those boards are generally frozen in time, but who knows Asus could go out of business two years from now. Nobody knows. From a customer support standpoint there is a strong case for an open source BIOS in the instance of any vendor that ceases to exist.

I think a mostly open BIOS with a blob is vastly superior to a walled garden. We are the ones purchasing these products, and we should receive at least "most" of the source as a part of that purchase contract as a hedge against interruptions in support, up to and including either the vendor decides "I don't want to anymore" or the vendor croaks.

[loganj]

so coreboot is only a dream as long as vendors does not open their blobs?

[AsuMagic]

Information on proprietary blobs is already provided in their documentation front page: https://doc.coreboot.org/
It would seem reasonable to me to move this information to its own chapter in this page, with a descriptive title.
Point out that there are forks like Libreboot, etc. that cut down the blobs to zero at the cost of narrower hardware support.

[phoron]

Are you interested in Coreboot for the idea of purely open-source firmware or its technical features and capabilities?

I was interested in coreboot for free software. But many years ago Intel and then AMD made it impossible (not sure about ARM, but I'd tend to include it). I was upset that coreboot accepted and encouraged it. It is not a question of how many blobs are there. It's also about the power they hold. And ME has a lot of power over users. It's also a problem of honestity. I can understand that a pro-bono project with the user interest in mind could not have enough resources to keep up with the excessive hardware diversity, but then people could perhaps focus on a few machines and leave the rest, or so. It feels increasingly worrying that not only the signed blobs are present, but also the "difficult" parts are left to vendor blobs. It might be expedient, but then don't advertise "open source" or free software, just your features. I see it in other projects too, like linux accepting firmware blobs or relying on ATF (PSCI) for arm64 (which is free under BSD style licenses, but then each SOC may have it's spicy particularity)... I don't know, I just get an overall feeling of make believe.

Business as usual, but business is so little sexy...

should Coreboot be doing more for acknowledging the binary bits often at play or any other suggestions for them in improving the clarity and intent of the project?

The bakery hiding the nutritional properties is I guess apropiate. They should be doing more if they'd mean to be honest. They won't because they mean to sell it.
Google is a marketing plot, and Coreboot was last I checked mostly manned by Google and their subcontractors... So what hope there is for honesty ?
I find it curious too, because it becomes second nature. Who are they trying to sell coreboot to ? gullible users who know no better ? Or hardware vendors who should do their due diligence and understand what is free and what not despite what the advertising says ? They're trying to sell to vendors, really, so they could really be more explicit and keep the same success. They might loose some volunteers, but volunteers without access to prerelease hardware and limited time to devote is not what carries the project forward anymore. What suggests to me that the problem is not that they mean to lie to others, but that they're trying to lie to themselves. Either they get over it or they don't but I doubt it depends on my opinion.

[woife]

On the subject: The pragamtic approach would be to accept the realities of today and thrive for an open future. And the initiatives of Intel and AMD are heading into the right direction. It might still take a while and might not be completely open, but considering the past I'd say it is still progress.

I fully agree.

And just because some blobs are still required doesn't mean that there is no progress.
Intel's FSP is often mentioned as an example, but FSP actually consists of three different parts:

• FSP-T: Initialize "Cache as RAM"
• FSP-M: Initialize RAM
• FSP-S: Silicon init

From those you only need the last two, because the first one is already implement in Coreboot.
(Details may vary depending on FSP version and platform, and I have only used Coreboot a few times, so don't take that information as fully reliable)

[c117152]

The problem is those blobs are a bit more than what most people would bargain for. Sometimes they're microcode updates patching erratas and security issues. Other times they're drivers and services for Intel's on-rom OS to html and vnc services that can be backdoored. You can never know since they're closed source and encrypted. And Coreboot, as open as it maybe, is what used to deliver them.

Personally I'd rather coreboot not advertise itself as open source. But the linux kernel does the same so the term is already diluted to mean whatever the fabs can get away with. No point in deluding ourselves we're not at the mercy of heavy silicon.