----- Original Message -----
From: "Patrick Georgi" pgeorgi@google.com To: "Timothy Pearson" tpearson@raptorengineering.com Cc: "David Hendricks" david.hendricks@gmail.com, "coreboot" coreboot@coreboot.org Sent: Monday, September 2, 2019 1:06:10 AM Subject: Re: [coreboot] Re: Web site revamp
Am So., 1. Sept. 2019 um 23:55 Uhr schrieb Timothy Pearson < tpearson@raptorengineering.com>:
This is an interesting take on the situation. Can you point to even one instance in the past few years where this strategy has yielded less vendor proprietary firmware (in terms of percentage of vendor firmware binary size to utilized coreboot codebase binary size) for a top-of-the-line platform vs. the older platforms? Is the trend line even going in the right direction?
You seem to mix up the temporary wins we had around 2007 (which involved, among other things, pressure put on vendors by what amounts to the CTO of a major industrial nation) with the original state of PC-era firmware. The trendline starts at 0 LOC that are open source.
we have reached the point where people are starting to simply say "the proprietary code is mandatory and unremovable, let's try to reverse engineer it instead to determine if it is safe enough to use since there is no other option". That capitulation means we've lost entirely when measured against the origins and above-stated goals of the coreboot project.
But that's how the project started out!
The early work was grassroots efforts inside mainboard vendors. That hinged on enthusiastic developers at mainboard vendors staying where they are (instead of furthering their careers and leaving their toys behind) and flying under the radar (which pretty much implies "doesn't scale": as soon as that stuff is noticed by silicon vendors, they shut it down through updated contracts).
Later, coreboot was picked up by government IT with high security needs. While you can get pretty powerful people to support you here, it's still only a tiny market. How often can you put pressure on a silicon vendor in that situation before they ask you to shove it? (experience says: not that often)
Where we are now is high volume deployments (Chromebooks on the portable side, Facebook infrastructure on the datacenter end). Again both of these started out at 0 LOC open source less than 10 years ago.
I like our trend lines (although I'd prefer them to be steeper, too).
I do understand, but at the time in 2007 crypto locking of anything was still pretty rare. Not that long before the fact that the TiVo was locked literally made headlines. We're now in a position where there are large, and growing, parts of the firmware that are simply off limits to this type of approach, and somehow we're not drawing a distinction between "can be replaced without vendor permission" and "vendor absolutely must go against its already stated goals to allow us to replace this part". I think we need to step back and have some serious discussion around that before we can really determine if the current approach is working.
Unless I'm mistaken, the firmware parts that have open source coreboot code in them now are *not* the parts that are locked behind the signing keys. It feels like we're sorta kinda maintaining status quo (maybe with a bit of vendor help now) for the unlocked parts, while completely ignoring the losses to the new signed/locked parts.
Again, I ask that the Website be updated to better reflect the distinction between project aspirations with no industry backing and the actual, on the ground reality of the situation, not just today, but over the past several years.
The mission statement of a hunger aid program isn't "feed 500k people", it's "end hunger". "Feed 500k people" is just a milestone.
You have something here...the Web site doesn't read like an unattainable (but admirable) goal. It reads like this is where we are today. When anyone says "end world hunger" they immediately understand just how impossible that really is, but understand as well it's an aspiration worthy of working toward. Coreboot on x86 doesn't have that kind of immediate recognition of the unattainable nature of the goal, and that is directly harming other architectures, systems, and projects where the goal is already attained today.