Am So., 11. Nov. 2018 um 00:43 Uhr schrieb Mike Banon <mikebdp2@gmail.com>:

But it is easier not to have any AMT/ME/PSP at all: no need to clean
anything and nothing to worry about.

At least not to your knowledge. For all we know, POWER9 (to pick the ISA where you can even edit the microcode) could have another processor in there that they "forgot" to tell you about. It just so happens to remove all protection levels when triggered by some sequence is found in the caches, eg. because it arrived over the network.

Unless there's progress on projects like the sadly defunct Home CMOS[0], there's some level of trust required that the hardware isn't nefarious.

So, is there really "nothing to worry about"?

Meanwhile you can't avoid the closed source Intel FSP the same way [as AtomBIOS].

FSP is also just software, and with no signatures. There have been successful efforts to replicate the functionality of very similar binaries (see Sandybridge/Ivybridge).

In addition, there is YABEL option in coreboot to prevent the
undocumented access of OptionROMs to other PCI devices - which also
helps to reduce the concerns regarding this AtomBIOS blob.

The AtomBIOS blob is parsed out by the OS, YABEL is long gone at that point.

I'm not sure there is any equivalent for FSP.

It might be possible to run FSP inside YABEL or x86emu. Sounds like an interesting experiment.

But they could still be removed from coreboot just because of "EOL and
old"/"no-one is using them". From coreboot 4.3 release notes: " 20
mainboards were removed that aren't on the market for years (and even
hard to get on Ebay) ".

Stuff like this could happen to any board that is old, or am I wrong here?

There were additional factors, but release notes normally aren't novels.

For the sake of completeness:

1. Not on the market for years

2. Not on the secondary market

3. No recent report (< 1 year old) on board-status at that point

4. No activity in related code that indicated that anybody would maintain it

5. Some of that code in question was getting in the way of modernization of coreboot's code base.

We could have kept the code around, but it would be all but guaranteed to be broken. We considered it better to send people using those boards to 4.2 which at least had a chance of still working on them.

And if they're serious about that hardware, they're more than welcome to step up as maintainers and bring the code back to master: The best way to avoid a board's deprecation is to maintain it.

> The (AMD) platforms are not the problem. Maybe the problem is that their fans got lazy and rested on AGESA, idk.
But maybe we are busy using our coreboot'ed AMD computers for
various freedom-related projects - as the tools to create something
great? And having to rewrite AGESA would mean we're suddenly working
much more on the tools than on the stuff we're creating with them -
without any obvious benefit to the
not-hardcore-programmers-but-security-conscious people who see that
AGESA is open source already

If there will be a time where keeping support for AGESA in becomes a real burden on coreboot development, and there is no maintainer for the boards based on it, expect to have to chip in the effort to keep support for those mainboards.

Nico's arguments are from the coreboot developer's and maintainer's point of view, while yours represent a certain set of users' - and both are valid.

However coreboot developers have no obligation to cater to the interest of any coreboot user (just like coreboot users are free to go elsewhere).

Excusing yourself from working on coreboot, including cleaning up the less savory parts, pointing out "various freedom-related projects" means that you won't have a voice in coreboot's future direction.

You're lucky though, the coreboot version that you're using on your AGESA based system won't go away. And if in the future there should be a reason to modify it, the source is also still there: just maybe not on the master branch.

Regards,

Patrick

[0] http://web.archive.org/web/20150424121156/http://homecmos.drawersteak.com/wiki/Main_Page

Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado