Coreboot Is Ridding Its Need For Intel's FSP-T Blob

[phoronix]

Phoronix: Coreboot Is Ridding Its Need For Intel's FSP-T Blob

Coreboot making progress on its temporary RAM initialization code (cache as RAM) means that its usage of the FSP-T binary blob is increasingly unnecessary...

https://www.phoronix.com/scan.php?page=news_item&px=Coreboot-FSP-T-Not-Needed

[Jabberwocky]

Regardless of platform, every day that Coreboot has improvements is a good day in my books.

Each time I read about Intel BootGuard I read it in the voice of Alex Matrosov ... He taught be about BootGuard https://www.youtube.com/watch?v=Dfl2JI2eLc8

[danmcgrew]

"...FSP-T causes more troubles than it actually solves, so having that code open sourced is the best strategy..."

Why, exactly, would Intel NOT want FSP-T code to be open source?...other than money, of course.


"Whatever they say the reason is, the real reason is always money."--the Old Philosopher

[avph]

"...FSP-T causes more troubles than it actually solves, so having that code open sourced is the best strategy..."

Why, exactly, would Intel NOT want FSP-T code to be open source?...other than money, of course.


"Whatever they say the reason is, the real reason is always money."--the Old Philosopher

Intel intends FSP to be used in other firmware solution. Coreboot has a history of being able to do all the hardware init itself, which conflicts with some of the things FSP does. Why that part is not open source likely has the same reason for why most things are closed in that industry. It's the default strategy: it has always been that way, so why change? Most companies adapt very slowly to changes. So I would not say it's about money at all actually.

[Developer12]

Why, exactly, would Intel NOT want FSP-T code to be open source?...other than money, of course.

As avph noted, closed source is often the default, simply because it takes action share code.

There's also lots of other posibilites one could speculate about. They might have a bias towards not sharing anything for fear of giving away a possible advantage. Or to not give away knowledge which could otherwise be counted as an asset. Or to avoid the work of cleaning up internal code because of the above. Or to avoid concerns of having to GPL other internal code (and a "GPL explosion") if the code they release re-licenced as GPL and interacts with it somewhere. (companies don't always have super-great visibility into how their own code is interconnected) Or because secrecy around the mechanism might be seen (incorrectly) as obfuscation to protect against rootkits/attacks. Or to protect against knowledge/subversion of software locks (like those disabling features the customer hasn't paid for). Or DRM schemes they get asked to include in their hardware by netflix/MPAA/etc.

Edit: Oh, or their code could just be garbage and they may not want to be mocked for it. That's also a possibility. The coreboot devs (and linux devs) love to rag on buggy BIOS code

Hell, I've heard anecdotally that closed-source code is more buggy/terrible/ugly than open source code purely because there's no expectation that anyone will see it. Even if your open source project is obscure, the knowledge someone might look at it may cause you to make better choices.

Lots of potential reasons. Pick any combination.

[Termy]

"Many free software enthusiasts continue longing for the day when modern Intel and AMD platforms -- and especially widely available desktop motherboards -- can work with Coreboot using a fully open-source stack."
As the latest Dell-Vulnerability illustrated perfectly...

[Developer12]

"Many free software enthusiasts continue longing for the day when modern Intel and AMD platforms"

Frankly, with intel and AMD burying important functionality deeper and deeper into the iron, x86 is becoming increasingly disgusting.

On AMD you can't even do this. It's not the BIOS' job to do ram init anymore.

That task has been wired into the Platform Security Processor (or whatever it's called now), a whole new realm of propriety hardware, OS, and applications, all cryptographically secured and heavily obfuscated. One on which the user has no foothold, never mind freedoms.

Buried deep in the silicon. This retreat away from the user and their OS, down through the bios, and down into firmware on isolated cores, is going to continue. It's the natural consequence of achieving the dream of creating a free-software OS, then a free software bios, etc.

[Developer12]

Reading through the blog post, it sounds like they've only swapped one blob for another. ie. they have an ACM which is loaded and verified by the Management Engine doing the work to set up cache-as-ram, before coreboot even starts. This is instead of coreboot starting up directly out of reset, and then calling into FSP-T to do the cash-as-ram setup.

In that case, you can only call it open-source from the standpoint of "I didn't call into a binary" (when in fact, the binary started earlier and called into YOU). If its "open-source" from the standpoint of "the vendor might release the source code of their ACM" then great, you can look at the code. BUT, it's still verified by the ME using THEIR key. You can't actually touch it/fix it/replace it. That's only good for a vendor using coreboot, and nobody downstream.

[avph]

Reading through the blog post, it sounds like they've only swapped one blob for another. ie. they have an ACM which is loaded and verified by the Management Engine doing the work to set up cache-as-ram, before coreboot even starts. This is instead of coreboot starting up directly out of reset, and then calling into FSP-T to do the cash-as-ram setup.

In that case, you can only call it open-source from the standpoint of "I didn't call into a binary" (when in fact, the binary started earlier and called into YOU). If its "open-source" from the standpoint of "the vendor might release the source code of their ACM" then great, you can look at the code. BUT, it's still verified by the ME using THEIR key. You can't actually touch it/fix it/replace it. That's only good for a vendor using coreboot, and nobody downstream.

ACMs are indeed closed source, but calling it swapping a blob for another is incorrect. Previously if you wanted to use Bootguard you needed a closed source ACM binary and closed source FSP-T. Now you just need the ACM binary. It's not free but it's an improvement. As a matter of fact FSP-T support was actually kept in coreboot just so downstream could use Bootguard, while there was no support for Bootguard in the master branch. So getting rid of that 'argument' makes things better. Complaining and bickering about the semantics of what is open has never improved anything to my knowledge.

[Developer12]

ACMs are indeed closed source, but calling it swapping a blob for another is incorrect. Previously if you wanted to use Bootguard you needed a closed source ACM binary and closed source FSP-T. Now you just need the ACM binary. It's not free but it's an improvement.

But, this ACM binary is implementing the CAR functionality of FSP-T, yes?

Complaining and bickering about the semantics of what is open has never improved anything to my knowledge.

It's nice to consolidate blobs, but to claim that the solution is now fully open source because you haven't loaded any blobs (ignoring you were loaded by one, which did the real work) is disingenuous.

It's why I also have a problem with the claims of "fully open source support" of ZEN by coreboot. This is only possible because the Platform Security Processor is doing RAM init instead of coreboot.