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

[schmidtbag]

This folder https://github.com/coreboot/coreboot...aster/3rdparty
Note that it's mostly a link to other repos with the blobs, as in many cases they don't even have the right to host or redistribute the blobs themselves.

So... they aren't providing the blobs themselves.
The blobs are not their work. They're not their prerogative.
What I really want to know is what do you make of distros that provide blob drivers? Are they suddenly no longer an open-source project, just because you can use a non-free repo? I don't see how Coreboot is any different - it is up to the user if they want to use a non-free repo.

Intel or AMD is the hardware vendor. Coreboot is a board firmware. The ones wanting a board firmware are the OEM (companies making the boards) or end users of such boards. And these parties need a NDA to Intel or AMD to be able to use the blobs (and Coreboot) at all.

As I said, it's not a "vendor that uses coreboot as closed source", but a Intel and AMD require any board port to use blobs that basically gut Coreboot.

Ok. And how does any of this determine whether Coreboot is actually open source?

It would if you replaced the more critical parts of it with blobs. It's not comparable to kernel modules. It's the core that is replaced with a blob.

Again - if the most critical parts are replaced, is it really Coreboot anymore?
This question matters, because if the most important parts of Coreboot aren't used, what's to say that they're actually using Coreboot? Like I said before, at that point it's basically false advertising. That doesn't in any way mean Coreboot's goals are compromised.

By that definition, even OpenGapps project is opensource https://github.com/opengapps/opengapps
Even if it is just a bunch of scripts that download and assemble binary Android packages from Google.

Um, no? Coreboot isn't just "a bunch of scripts". You're comparing apples to oranges here.

I mean, all we care is that we can legally call it "opensource"? Not that it can actually be tinkered with and worked on by people without NDAs.

Right, and as far as I'm concerned, all of Coreboot, from github, is open-source. It's implementation on most motherboards might not be, but that doesn't detract that Coreboot itself is open-source.
Just like how 2 wrongs don't make a right, taking open source code and sticking proprietary software in it doesn't make the original source code closed-source.

[pgeorgi]

Which is mandatory for modern hardware?

So where's your patch to reimplement ram init for some modern hardware?

[pgeorgi]

This folder https://github.com/coreboot/coreboot...aster/3rdparty
Note that it's mostly a link to other repos with the blobs, as in many cases they don't even have the right to host or redistribute the blobs themselves.

Wrong, again. The FUD is getting old.

We host these repos ourselves (all of github.com/coreboot is a read-only mirror of review.coreboot.org, all of these submodules point to our repos). We secured redistribution rights for everything because we don't feel like breaking the law.

And these parties need a NDA to Intel or AMD to be able to use the blobs (and Coreboot) at all.

These blobs can be used according to the license terms, which don't require NDAs.

As I said, it's not a "vendor that uses coreboot as closed source", but a Intel and AMD require any board port to use blobs that basically gut Coreboot.

Wrong, again. coreboot still controls the boot flow. It's up to coreboot to decide when the blobs are executed.

It would if you replaced the more critical parts of it with blobs. It's not comparable to kernel modules. It's the core that is replaced with a blob.

The core could be the boot state machine that defines the boot flow across all stages, which is open source. Or the resource allocator (which essentially drives the ramstage), which is open source.

No, FSP or BinaryPI don't replace "the core".

[davidhendricks]

This folder https://github.com/coreboot/coreboot...aster/3rdparty
Note that it's mostly a link to other repos with the blobs, as in many cases they don't even have the right to host or redistribute the blobs themselves.

Again, only enabled with CONFIG_USE_BLOBS. It's not generally mandatory from coreboot's standpoint, though if one is playing in the x86 ecosystem then they need to deal with the restrictions that x86 vendors put on them.

As I said, it's not a "vendor that uses coreboot as closed source", but a Intel and AMD require any board port to use blobs

So your beef is with Intel and AMD. Complain to them.

It would if you replaced the more critical parts of it with blobs.

Some consider the responsibility of blobs like FSP and BinaryPI in its basic role of silicon init (and I know they do more than "basic" init) to be less interesting than the payload which is responsible for accessing networking and storage resources to load the OS. Even on x86 platforms that use those blobs, coreboot still buys the user a lot of freedom here since there would be no viable alternative for installing a user-controlled payload.

(ME/PSP are a nightmare of course but those are orthogonal to coreboot's role in the system)

I mean, all we care is that we can legally call it "opensource"? Not that it can actually be tinkered with and worked on by people without NDAs.

coreboot has quite a few libre-friendly boards - some x86, some RISC-V, some Aarch32 and Aarch64. Granted we'd like to see that number increase. Maybe someone can add a Talos port ;-)

[madscientist159]

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

I've made no secret of who I am here. Not only is that same username on Github etc. under my name, I've mentioned many times here working for Raptor. In fact if there's a way to add corporate affiliation to the forum here I'm all ears.

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/

Bzzzzt. In fact the BCM5719 is probably one of the most well understood commodity GbE NICs around, and it has open firmware now:

https://github.com/meklort/bcm5719-fw

Oh, and the driver you want is the "tg3" driver in Linux mainline. The one that's, you know, automatically selected by the libre (deblobbed) kernel if you bother to install Linux on one of these platforms?

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!

Bzzzzt. Here's your early graphics init: https://git.raptorcs.com/git/blackbird-openbmc/ , also check out all the native init for that 2D GPU in https://git.kernel.org/pub/scm/linux...gpu/drm/aspeed Next time do a little research about how GPUs are started before whining about blobs in areas they simply don't exist.

I'll grant you the datasheet though; while anyone can request a copy from ASpeed they do want an NDA before sending it out. There's a reason we're looking beyond ASpeed for the next generations of our products -- while we can't do much about a suddenly stonewalling vendor in one product generation, we do take notice and fix things (by replacing that vendor's parts) for the next generations.

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

You must be confusing the more typical closed, signed x86-class BMC firmware with the OpenBMC firmware we use. If you don't want network on your BMC, recompile OpenBMC without network and flash it to your hardware -- no NCSI setup, no way for the NIC to talk to the BMC period. Or use one of the hardened BMC firmware projects that have sprung up because we actually have owner controllable hardware (funny how that works). Done.

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.

Bzzzzzzzzt. We designed in that part specifically because you can run synthesis on our open HDL (https://git.raptorcs.com/git/talos-system-fpga/) using the completely open source IceStorm tooling. But please, do continue to make accusations without any research whatsoever, this is exactly why I want the coreboot wording updated to be clearer to people that think they understand things they apparently don't.

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.

We've made no secret of our domain-based security model over the years, which basically comes down to a hard requirement for full code and full owner control of the CPU domain, and somewhat more relaxed requirements for devices on the other side of the IOMMU. For instance, disk firmware in general does not concern us (even when older blob-free coreboot is used) because all data stored on those disks is encrypted by the (trusted) CPU, and non-encrypted data never crosses the IOMMU to the disk controller, let alone the disks themselves. For GPUs we draw the line at compute -- the worst thing malicious firmware on a properly IOMMU isolated output-only GPU is going to do is DoS you, and even then you simply return the GPU as defective under warranty and select another. Compute is trickier due to the potential for selectively corrupted results, which is why we highlight that potential and continue to call for DRM-free, open firmware, compute-oriented GPUs.

Also, you will note the Blackbird line (released after Talos II) sports a blob-free SATA controller. We continually improve our products where we can, including in the open aspects.

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?

Yep. You'll note that on the coreboot list I never mentioned our products. Yes, the request was made for marketing purposes, but not for the sake of POWER, and not for Raptor's sake. x86 continues to be marketed as open and owner controllable when the truth is very different -- this false advertising harms anyone that wants any form of owner-controlled computing outside FPGAs, be it RISC-V, MIPS, POWER, or something else entirely. When people think they are getting an open platform on x86 it removes the desire to switch, increases the gravity well binding people to x86, and overall harms every single non-x86, truly owner-controlled vendor. This then translates to direct harm to consumers purchasing products for those requirements, both in diminished selection and in higher prices.

x86 is one of the most closed, restricted, locked, and generally anti-owner architectures on the planet. The only other architecture that springs to mind as locked tighter is Z. x86 processors can only be made by two vendors (*maybe* three, though the relevance of that third vendor is in question). FPGA-based reimplementations of the x86 processors are illegal. Emulation of x86 outside of some small (old) subset is illegal. Both x86 vendors have moved to force the use of management processors that take large binaries and check vendor signatures before allowing platform start. In what world is x86 even remotely interesting for anyone that wants true control of their machines from firmware through the hypervisor, kernel, and OS?

[madscientist159]

(ME/PSP are a nightmare of course but those are orthogonal to coreboot's role in the system)

This is a curious statement. Can you elaborate further? I'm especially interested in how and under what criteria this new line is drawn between early platform init by ME/PSP (which used to be completely handled by coreboot bootblock/romstage) and "coreboot" proper. What specifically is pushing early platform startup outside of the domain of coreboot, and why?

[davidhendricks]

I'm especially interested in how and under what criteria this new line is drawn between early platform init by ME/PSP (which used to be completely handled by coreboot bootblock/romstage) and "coreboot" proper. What specifically is pushing early platform startup outside of the domain of coreboot, and why?

You'd have to ask the vendors who architect their systems this way. Maybe it's easier to implement and validate code on an independent microprocessor rather than an x86 core in CAR. Or maybe they don't own all the IP and rights to publish the code. Or maybe they're lazy. Or maybe they're monocle-wearing super villains or something.

Of course the more in the open the better. If you'd like to see something done in coreboot rather than elsewhere, patches are welcome. Personally I like your approach of implementing a real product that is more open than anything coming out of the x86 world. Hopefully somebody with enough time can add coreboot support for it, the templated C++ firmware that currently runs on it ain't my cup 'o tea but at least it's open and might be a good enough starting point.

[madscientist159]

You'd have to ask the vendors who architect their systems this way.

I'm confused. Before the ME/PSP, coreboot determined its own architecture, it didn't artificially segment the firmware stack into "non-coreboot" and "coreboot" pieces. It replaced all of the system firmware present on the platform ROM/Flash without drawing any distinctions about pieces running on the main processor, auxiliary processors, etc.

Why are the vendors now determining what is (conveniently, IMO) considered orthogonal to coreboot? What stops a vendor from simply determining all of romstage is orthogonal to coreboot?

In any case, yes, given the bad situation we are attempting to lead by example. This becomes difficult, however, when the hard lines of open/owner controlled systems are blurred by arbitrarily deeming vital platform firmware on certain locked platforms as "orthogonal" or not important somehow.

[pgeorgi]

Before the ME/PSP, coreboot determined its own architecture,

Not really. coreboot always had to follow whatever the platform defined: Before we had cache as ram, we had to go through romcc to get code to work, we couldn't simply architect ourselves some memory to work with. Without the romcc history, coreboot might (arguably) look quite a bit different from what it looks like today.

it didn't artificially segment the firmware stack into "non-coreboot" and "coreboot" pieces. It replaced all of the system firmware present on the platform ROM/Flash without drawing any distinctions about pieces running on the main processor, auxiliary processors, etc.

I'd count the Embedded Controller in laptops to be part of the "auxiliary processor" set, sometimes it shared the flash with the AP firmware. coreboot better left that alone, so there were distinctions to draw from the start.

Why are the vendors now determining what is (conveniently, IMO) considered orthogonal to coreboot?

Because they always did so by defining their platform. Why do you expect them to stop?

What stops a vendor from simply determining all of romstage is orthogonal to coreboot?

They do, see Ryzen. There's a bunch of reasons why they went for that design and we're not sufficiently established with all the relevant teams at AMD to provide input early, so that these reasons are reconciled with platform ownership goals. So now we have to react again and see how to get them to accomodate us in their architecture moving forward. The only reason why we can even do that is because we work with them, despite their platform's shortcomings.

In any case, yes, given the bad situation we are attempting to lead by example. This becomes difficult, however, when the hard lines of open/owner controlled systems are blurred by arbitrarily deeming vital platform firmware on certain locked platforms as "orthogonal" or not important somehow.

I think the issue is more that you see your approach as the only viable one.

It's certainly _one_ viable one, but it also comes with risks: suppose such an open platform takes off. Users want that platform (no matter the ISA or vendor) in the millions. Users also want to continue to watch Netflix. Netflix requires DRM. The silicon vendors aim to please the millions. Sadly, your ecosystem is completely unexperienced with dealing with such a situation (because so far all vendors were _super_ happy of having you and your couple dozen buddies, despite your weird demands, because that was a couple dozen more than before), and so the DRM steamroller (millions >> couple dozens) just destroys your little pocket of owner controlled hardware. There are a few other such things that pop up and lead to similar problems, but DRM is the one that's the easiest one to follow.

I see the first signs of that in the RISC-V ecosystem.

We're dealing with all these messy issues right now, and we're working on establishing a rapport with stakeholders. If we can use that to transform the platform to an open architecture (while keeping Netflix happy for those who insist on using them), all that annoying crap is already accounted for instead of jumping at us at the most inopportune time.

So here we are, approaching a similar goal from different angles. In case you wonder why I'm pissed off about your campaign given that we share goals: I'm (again, since this crap is just the latest in a very long line of - hopefully - well-meaning attempts to get other open source firmware folks to "see the light") wasting days to contain the damage it inflicts on the project instead of working towards a better future of computing.

[madscientist159]

Not really. coreboot always had to follow whatever the platform defined: Before we had cache as ram, we had to go through romcc to get code to work, we couldn't simply architect ourselves some memory to work with. Without the romcc history, coreboot might (arguably) look quite a bit different from what it looks like today.

Agreed. I'd argue it'd have far smaller market share and wouldn't be assumed open source by people that hear the word "coreboot".

I'd count the Embedded Controller in laptops to be part of the "auxiliary processor" set, sometimes it shared the flash with the AP firmware. coreboot better left that alone, so there were distinctions to draw from the start.

I'd argue not, for the simple reason that the EC is completely separate from the main CPU (by separate, I mean it can't DMA to main memory or meaningfully influence the operation of the main CPU beyond power on/off). That being said my contention would be that coreboot should also work to replace the EC code in such situations; this is an area where Google sets a good example with the Chromebook EC code.

They do, see Ryzen. There's a bunch of reasons why they went for that design and we're not sufficiently established with all the relevant teams at AMD to provide input early, so that these reasons are reconciled with platform ownership goals. So now we have to react again and see how to get them to accomodate us in their architecture moving forward. The only reason why we can even do that is because we work with them, despite their platform's shortcomings.

We tried to work with them in the past. They were simply not interested, in fact going so far as to say basically their entire profit margin comes from consumer devices that require strong DRM. That's not exactly the kind of response that indicates "if you just work with them some more they will change".

I think the issue is more that you see your approach as the only viable one.

It's certainly _one_ viable one, but it also comes with risks: suppose such an open platform takes off. Users want that platform (no matter the ISA or vendor) in the millions. Users also want to continue to watch Netflix. Netflix requires DRM. The silicon vendors aim to please the millions. Sadly, your ecosystem is completely unexperienced with dealing with such a situation (because so far all vendors were _super_ happy of having you and your couple dozen buddies, despite your weird demands, because that was a couple dozen more than before), and so the DRM steamroller (millions >> couple dozens) just destroys your little pocket of owner controlled hardware. There are a few other such things that pop up and lead to similar problems, but DRM is the one that's the easiest one to follow.

I see the first signs of that in the RISC-V ecosystem.

RISC-V always had issues with this. As was said once to me, the easiest way to get a RISC-V CPU is to buy an NVIDIA GPU. It's meaningless in terms of doing anything with it aside from running NVIDIA signed firmware, but it's a RISC-V CPU nonetheless. I'm not surprised at all given its positioning in the market that it will tend to sell well for DRM applications. That being said, as an open ISA there is absolutely nothing stopping the smaller scale manufacture of decent RISC-V chips that are aimed at DRM-free compute -- with x86, the associated legal barriers are insurmountable.

We're dealing with all these messy issues right now, and we're working on establishing a rapport with stakeholders. If we can use that to transform the platform to an open architecture (while keeping Netflix happy for those who insist on using them), all that annoying crap is already accounted for instead of jumping at us at the most inopportune time.

So here we are, approaching a similar goal from different angles. In case you wonder why I'm pissed off about your campaign given that we share goals: I'm (again, since this crap is just the latest in a very long line of - hopefully - well-meaning attempts to get other open source firmware folks to "see the light") wasting days to contain the damage it inflicts on the project instead of working towards a better future of computing.

Frame challenge: why do you assume Netflix DRM has to be in the CPU? In fact why does Netflix DRM have to have access to customer data period? The absolute safest, less breakable way to do Netflix DRM is to point the encrypted data stream at a Netflix compatible GPU and tell it where to render. Let us have our CPUs for our own use. Has this approach even been mentioned to the vendors or have you already conceded control of the CPU entirely for DRM purposes?