Am Fr., 5. Nov. 2021 um 18:16 Uhr schrieb Martin Roth via coreboot < coreboot@coreboot.org>:
The current reality is that binary blobs are needed for almost every platform in coreboot. I believe the coreboot leadership is united behind the unfortunate reality that allowing these blobs is a requirement for the platform. I don't think we're going to refuse a platform right now simply because it has blobs. I'm not sure what coreboot would look like right now if we'd started refusing blobs when the required blobs started appearing, but it definitely wouldn't have many modern platforms.
It would be dead: while there are still a few folks carefully maintaining i945 and GM45 in this reality, I'm not sure they would have done so in that other reality where there was no help maintaining the payloads (and so coreboot-compatible seabios, tianocore, grub, filo, ... would all be on their plate as well)
We all agree that we don't like adding more proprietary binaries, but there
are times when a binary needs to be closed for a time until the platform is released such as with the PSE.
There's a UPD called PchPseEnable - I wonder what it does if you set to it 0? ;-)
Maybe the coreboot organization & SFC can enter into a contract that
specified a rough timeframe that the firmware would be open sourced. Hopefully that would be enough of a guarantee.
That would be the SFC (coreboot org is not a separate legal entity). We could ask and I suppose it would further the SFC's missions (more Software Freedom!), but it's not something they already do routinely, and last I heard they're pretty swamped with work already. That said: If we ask, the worst they can do is say "no", right?
Simply refusing to accept the binaries *only hurts us*, most companies will
be probably happy using Slimboot or TianoCore. Making things difficult to work with coreboot only makes it easier to show why something shouldn't be open and why the chip vendors shouldn't work with coreboot. I cant tell you how many times I've heard that the reason coreboot wasn't used or wasn't upstreamed was that it takes too long to get changes into coreboot.
Compared to pretty much every other project (including high profile stuff like Linux, and don't get me started on the mess that is u-boot forks), coreboot is doing a relatively good job at coalescing developments upstream.
These things said, I think we can come up with solutions to make things
easier. Ron suggested several years ago that we could enable Kconfig to only show the platforms with the amount of binaries that people are comfortable with. Maybe we need to look into that more.
It's work - and lots of it - to get this to the granularity needed to satisfy everyone. And then it needs a dedicated "librarian" role to keep all new development categorized properly. Much as I like the idea, we're already spread thin so I just don't see that. (I guess that's a complicated way of saying: contributions desired!)
(And then it also differs by desired feature set: while I don't know who in their right mind would use TXT, SGX or any of the other toys pretending to improve security, apparently there are such folks, and on some platforms enabling these means "optional blobs". So the set of platforms differs by "blob level" _and_ feature set.)
We can require that the soc/cpu/chipset Kconfig screens display what blobs
are required.
Few people see those screens.
We can push to get anything we can moved from the blobs into coreboot. We
can, and we are, pushing the vendors to be more open-source friendly, and we're finally starting to see some more and more people at these companies buying into this.
This is something I can only emphasize: there is movement in the right direction - and there's also a struggle to not let things slip back, but lots of these things happen behind closed doors. "Trust us" is always a hard sell, but if you don't trust us, look elsewhere and see how much better it gets?
Patrick