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

[SystemCrasher]

You're assuming that there was any pressure we could have exerted on vendors in the first place.

Yes. Just like Linux does. Sure, you can't come to vendor and demand dox, src or smth. But if your project turns to be Good Thing, others could do that part, asking vendor for "coreboot support" (or more generally, "opensource boot loaders & firmware"). It puts pressure, I'm dead sure about it.

Well, IF. Looking on topic, that's could be an issue. I'd say thanks to half-blob approach it looks more like Snake Oil or False Advertisement rather than Good Thing.

i945 support was a one shot stunt that took years and _lots_ of resources that we can't rely upon all the time, such as the CISO of a major industrial nation stating that they'd reevaluate the use of their products across the entire government if Intel doesn't support that port, and even that only succeeded when the platform was already dead from Intel's perspective (that is, few secrets worth worrying about from their point of view, for example because they've already moved on from DDR2).

My personal opinion on all this:
1) China, and even Russia managed to design their SoCs&CPUs instead of s... Intel's [CoC]. Far better terms, more cooperative HW teams and so on. China companies even managed to get nice margins out of this.
2) These days CPUs&SoCs suitable as laptop or even desktop designed by fairly small startups. These offer better terms, they can't afford to be as toxic and troublesome as Intel and dreaded "independent" vendors. IMHO later better burn in hell alltogether. Being better in various regards, including these aspects is what gives less toxic companies a chance. What startups lack in nanometers, R&D and so on, they make it up in better terms, prices, agility and being at client side.
3) Needless to say 1) and 2) do not have to enjoy by non-removable Intel backdoors. Quite a consideration, especially for gov and somesuch, no? I think mentioned HW dev teams can offer much better "risk assessment" to their govs than you ever stand chance to deliver.
4) Sure, such CPUs and SoCs aren't best of the best. But there is notion of "good enough" and it seems Intel wouldn't give best terms either, at which point such activity seems to be well justified.
5) Granted all that I fail to see how or where "major industrial nation" showcased... that part of theirs.

TL;DR next time "major industrial nation" gov could try, to, say, fire x86 fans, send Intel where it belongs, hire sane ppl and design CPUs/SoCs and SW around. If even Russia can afford that... lol, dammit, there could be no excuse except maybe being banana republic. Wait, even these started doing some comparable techs?!

Now we're in the situation where companies and business units whose DNA normally is "all closed all the time" are contributing to coreboot out in the open (yes, there's open source code in the final image that is copyright Intel). That's probably the worst time for us (at large, not speaking about you individually) to pack our things and leave, because then they really will revert to their bad old ways.

Speaking for myself I don't get why treacherous uncooperative proprietary vendors and backdoored HW are such a valuable assets anyway. Nor would I take FSP-blobbed something for "opensource" solution. At most I can take if for false advertisement if that's what you guys really up to.

You don't feel like trusting x86 vendors anymore? Fine, use something else. You can even use coreboot there (as you noted yourself), and we gladly help you get up to speed and integrate your contributions. The more fully open firmware code we have, the better, as it showcases to the frightened vendors (Intel etc) that there's nothing to be afraid of. But for projects with a different risk profile the compromises that x86 requires these days may be acceptable and it would be a shame to tell them they have to go to 100% closed (e.g. by using the products of the big IBVs) because we're unwilling to even try to move the ecosystem.

Well, on technical level coreboot made me a bit curious. But I can sense trying to bring up something like ARM SoC could be rather big adventure and I'm afraid it wouldn't be very exciting for me, rather bringing me a lot of frustration instead. Haven't I said I consider Intel, x86 IBVs and somesuch most toxic ecosystem I ever met? At which point I got to think in long shot I may want to have just bare minimum firmware that can kick me linux - and if I need advanced stuff like GFX boot, parsing complicated filesystems, flashing OS image or so, it would do. And I like their handling of blobs better than yours, sorry. At least they don't generally let blobs on main cpu and I can more or less count on this policy, considering it Good Thing.

We're also open to provide better information about the required or optional blobs for each platform, but not to the point of twisting our mission statement into something that you or Timothy think is our mission but isn't. We define our mission ourselves, thank you very much.

Oh sure, I can't order you something. And I'm capable of understanding it, lol. I can only suggest something and express opinion - I thought it pretty clear from context? Speaking of later, I think you can't screw mission statement anyhow further. I'd dare to think it rather time to unscrew it a bit maybe? Because from what you told it basically follows you going to appease Intel no matter the cost. Even if it means no longer being opensource and so on. Well, sounds sad, but... as you've correctly told I can't order you to change that.

Addendum: I'm not sure if the Wright Brothers had a mission statement (not sure if they were popular back then), but it would probably have been something along the lines "enable people to fly". Their detractors (of which there were many) probably would have tried to coerce them to change it to "part as many people from their money as possible".

I think a mission statement should be defined by the desired goal ("make people fly"), even if those on that mission fail and the result was a different one ("parting people from their money"). By insisting that we "change" our mission you essentially tell us that we failed. Not very nice, but who's to argue with an opinion? But if we failed, we wouldn't need an amended mission statement, the most reasonable course would be to cut our losses and shut down the project.

Since we don't, we obviously don't believe that we failed.

Oh, imagine Wright brothers and other inventors and scientists doing all that Intel ways? So let make all laws of physics secret, only supply pre-made wings, propellers and somesuch, conceal all knowledge and techs how to actually make all this. That's what all these FSP, ME, PSP and murky blobs really up to. Wouldn't world like that suck a bit too much if you're denied learning aerodymanic laws on your own, with the only option being to buy some strings, wings and things from 1-2 vendors, and if they don't make what you want ... ok, you have no clue how to do that and therefore screwed. Even more fun if 1-2 megacorporations would go overengineered and put remote controls to ensure they can blow you out of the sky at will, by merely making wings falling apart at their sole discretion. Somehow I'm not excited about world like this.

Look, I do think when someone creates something good, it fair if they are rewarded. However there're limits on how far it should go, and I think Intel, "independent" board vendors and so on long exceeded all sane limits, turning into toxic proprietery troublemakers with numerous hidden agendas. By any means, these aren't scaredy cats. And even if you get 'em in, I'm afraid they wouldn't stop their hidden agenda folly and corrupt your ecosystem instead. From what you told it seems they already did.

So if it comes to question if you failed or not... I don't know. From your words I got impression you more about "appeasing HW vendors" rather than something else, that part maybe not failed, but let assume I'm not curious enough to figure it out. I have more pleasant things to do, for example.

Either way guess I should thank you for keeping me more up to date on what to expect from that project and so on. Even if I dislike it, at least it makes things clear.

[pgeorgi]

Yes, and I think option to use blobs on coreboot side caused a lot of harm in this regard, reducing pressure on vendors, so they can throw some blob and consider mission complete, happy manager marks [x] we support coreboot... but then we notice devil hides in details. Details... that's what I really dislike about modern x86 ecosystem. Maybe because I'm at least trying to understand what hardware can do.

You're assuming that there was any pressure we could have exerted on vendors in the first place.

i945 support was a one shot stunt that took years and _lots_ of resources that we can't rely upon all the time, such as the CISO of a major industrial nation stating that they'd reevaluate the use of their products across the entire government if Intel doesn't support that port, and even that only succeeded when the platform was already dead from Intel's perspective (that is, few secrets worth worrying about from their point of view, for example because they've already moved on from DDR2).

Now we're in the situation where companies and business units whose DNA normally is "all closed all the time" are contributing to coreboot out in the open (yes, there's open source code in the final image that is copyright Intel). That's probably the worst time for us (at large, not speaking about you individually) to pack our things and leave, because then they really will revert to their bad old ways.

You don't feel like trusting x86 vendors anymore? Fine, use something else. You can even use coreboot there (as you noted yourself), and we gladly help you get up to speed and integrate your contributions. The more fully open firmware code we have, the better, as it showcases to the frightened vendors (Intel etc) that there's nothing to be afraid of. But for projects with a different risk profile the compromises that x86 requires these days may be acceptable and it would be a shame to tell them they have to go to 100% closed (e.g. by using the products of the big IBVs) because we're unwilling to even try to move the ecosystem.

We're also open to provide better information about the required or optional blobs for each platform, but not to the point of twisting our mission statement into something that you or Timothy think is our mission but isn't. We define our mission ourselves, thank you very much.

Addendum: I'm not sure if the Wright Brothers had a mission statement (not sure if they were popular back then), but it would probably have been something along the lines "enable people to fly". Their detractors (of which there were many) probably would have tried to coerce them to change it to "part as many people from their money as possible".

I think a mission statement should be defined by the desired goal ("make people fly"), even if those on that mission fail and the result was a different one ("parting people from their money"). By insisting that we "change" our mission you essentially tell us that we failed. Not very nice, but who's to argue with an opinion? But if we failed, we wouldn't need an amended mission statement, the most reasonable course would be to cut our losses and shut down the project.

Since we don't, we obviously don't believe that we failed.

[SystemCrasher]

As you say, libreboot is a downstream fork of coreboot (i.e. not the same as coreboot). It's made possible by the fact that there was enough work done in coreboot to enable them to start a business and add value for their customers by making it more libre. That's a great thing IMO and certainly more productive than all the people complaining about the situation using non-libre systems.

Sure thing. Yet, speaking for myself, at the end of day, I'm not terribly excited about e.g. buying refurbished lenovo where ME "asked to pike off" with no means to check what it really does (?). And if it comes to newer hardware I would expect more shit from vendor like Intel. Now its like iPhone: you can jailbreak old version, but newer HW versions would get "fixed".

The result is hostile platform and hostile vendors. I liked PCs because they were open platform where everyone invited, multiple vendors, no hard vendor locks, open standards, any OS of choice, etc. Somehow now PCs aren't that anymore - I think most fair thing I can do is to admit PCs I knew and loved no more. Not even coreboot can really fix that. Even less so with blobs.

There are no blobs in coreboot, they exist in 3rdparty/ as submodules (additional git repositories on the same server) and imported only if the user enables CONFIG_USE_BLOBS. So in that regard it's similar to linux-firmware, and I don't see anybody demanding that kernel.org add an ugly warning to their homepage, even though linux-firmware is in fact hosted on git.kernel.org.

Give that option and vendors would decide its way to go. Without bothering to provide better options (low level HW details, opensource code, ...). Sorry, I do not think such frankenstein brings benefits people expect from opensource. At which point I would consider goals jeopardized. OTOH vendor mumbles "[x] we support coreboot; [x] opensource" and considers mission accomplished. That's what gives rise to mentioned question I guess.

AMD with their PSP wasn't much better. IIRC they gone as evil as PSP (?) doing DRAM training or so (!!!). So PSP is pivotal in critical part of boot sequence - and I really doubt that part is going to be opensource, doing its job from code I've built, etc. I guess such design is exceptionally hostile to opensource, verifiability and trustworthy computing. I'd say this folly gone way too far and if someone pretends they can wing it, I would take it with grain of salt unless I see really convincing proof how they dealt with isssue. Oh, btw, merely "disabling" PSP in BIOS setup, or even throwing some "packet" to "management interface" yourself is bullshit. Becaust then there is no good way to check what really going on and what the worst it can really do.

Linux supports EFI runtime services implemented as proprietary UEFI firmware modules

I can name few opensource uefi implementations, just in case. Even intel's stuff is formally open, though it BSD-licensed, so no way you would ever see sources of actual MB firmwares, that's how BSD licensing works in practice and reminder on why Linux did right by choosing GPL and being hostile to proprietary parts. However it wasn't a point. Firmwares were proprietary long before kernel appeared. Kernel used firmware interfaces and whatever "services" long before UEFI. If it wouldn't, it generally can't boot, not even on i386, where you also have to use BIOS and its "services". At least before kernel fully takes over. And even then there would be APM, ACPI, SMI, etc which are "firmware runtime services" one way or another. Later is impossible to avoid by kernel. But its FW/HW <-> kernel interaction, it isn't kernel's area of expertise (ability to liberate this further would be welcome, but it likely far off the track for OS kernel). I've referred to kernel <-> its parts. I'm sorry, if FSP have to be there to init HW, etc - it like "part of coreboot" in this sense (same functional level, binary, privs level). And in this sense, I can't imagine Linux kernel devs accepting proprietary x86 kernel code to their mainline tree from e.g. Intel. As for git.kernel.org, it hosts ton of projects of different relevance. These projects != Linux kernel. As we know, good things are better to happen late than never. Splitting firmwares from kernel is exactly that. There were fairly good technical reasons why it could be that way: if driver brings up their HW and at this point figures out its hw MCU needs external firmware before getting operational, you have to provide it at exactly that point. At which point driver can't fully disregard firmware question, its part of HW init sequence. On kernel side ... it took some time and then coding and refactoring before problem got widespread and understood to justify these changes. Now drivers can request "firmware file" loading in generic way and kernel would try to fetch it for driver, if it can. This way firmware loading got more or less decoupled from drivers, so kernel can proceed with splitting firmwares out. But it wasn't feasible without generic firmware file loading mechanisms though, which only appeared relatively recently and actually gone kernel-side after rather funny kernel vs usermode dev clashes. At which point kernel side yanked feature and generally won battle, though there is still "usermode helpers" fallback, now more like historic reminder or fallback in case one needs something really unusual.

Nicely done! And hopefully others can learn from your workflow.

Look, I've seen fairly nasty secureboot schemes long ago. Does, say, "Nokia BaseBand 5" rings a bell? (A fairly custom TI OMAPs, one of earliest full implementations of secureboot). When MS started demanding "drivers signatures" and "activations" in XP I've got rather clear idea how it would develop - and now, many years ago, I have to admit it keeps predicted course and mostly completed evil scheme. And even eventually dared to activate it, to extent WinRT tablets wouldn't boot Linux, etc. Fortunately WinRT is dead, but overall scheme is here, even on x86, and it already gone nasty - hardware no longer belongs to user, who is no longer true owner. True owner is one who fused some obscure "master key". Somewhere. Deep inside. Usually one-time operation. That's what real HW root of trust happens to be. In case of x86 it seems to be ME, in case of AMD it likely PSP. And no way AMD/Intel+MB vendors would let user to put own "master key" to ensure HW actually bows down to its owner. So now HW belongs to someone else except 2 cases: 1) "Virgin" HW where secureboot master key is not fused or 2) You can fuse your own master key. Seems x86 doesn't allows for these options at all. For Intel it would likely be boot guard key + ability to generate ME signatures.

Everything below this level is fake. As for UEFI, it would at most allow user to put some keys. Permitting to boot their SW. However, it isn't master key and it isn't full control. Furthermore, one can't generally delete (MS, Intel, AMD, ... ) keys - HW retains its true owner. Who knows how or when it would serve to real masters, when HW is proprietary and you can't replace murky ME/PSP firmware with your code? I can even propose funny "generic backdoor" schemes based on that.

The values are stated plainly on the homepage ;-) The hard part is achieving them.

Yes, and I think option to use blobs on coreboot side caused a lot of harm in this regard, reducing pressure on vendors, so they can throw some blob and consider mission complete, happy manager marks [x] we support coreboot... but then we notice devil hides in details. Details... that's what I really dislike about modern x86 ecosystem. Maybe because I'm at least trying to understand what hardware can do.

One more thing I'll add - coreboot is currently in its 20th year. There was a recent talk about this (videos will be up soon): https://osfc.io/talks/anniversary-keynote. It was made possible by the fact that 20 years ago one could simply go to developer.intel.com and download all the datasheets needed to write a BIOS. It was started because the original author had problems with the BIOS on a cluster of servers in an HPC environment and had no way of auditing the BIOS (important for a machine running in a research lab with classified materials) and couldn't debug or fix issues.

Congrats to project and its devs. After all it some curious set of techs and knowledge. But speaking for myself, I think in long shot I'm better off going away from x86 ecosystem at all, with all its treachery and problems. Both Intel and AMD put a great deal into backdooring their hardware - and it isn't open hardware/instruction set/etc either. At which point things are so screwed I do not think someone can really unscrew it. It isn't coreboot fault though. IIRC coreboot even supports some far less broken platforms like some Rockchips.

My point is that coreboot predates ME/PSP/FSP/etc. by a long shot. The goal was never to support blobs, those were incidental to the evolution of x86 architecture. The goal, as is currently stated on the homepage, is to provide auditability and maximum control to the user.

I guess blobs support hardly helps this goal, quite the reverse. Sure, it brings short-term gains, but what about price? These days it gets harder not to be goofied by half-open/unobviously-backdoored treacherous solutions which pretend they are free, while deep down inside still serving to their true masters.

[davidhendricks]

One issue with diverse projects like coreboot is that they're a projection field for lots of different crowds and the hard part is really to avoid that any of them take over and drive out all the others. Hence the opposition to go all-in on any demands.

Very well said!

[davidhendricks]

Look, as far as I know, e.g. Libreboot appears to be "deblobbed Coreboot". It gained some popularity on these grounds, despite whole project being just like few scripts to deblob coreboot rather than some major "system works", if I got it right. So there was demand to ensure it happens this way, no?

Yes, there is certainly demand. Enough that someone (Leah Rowe) set up a business around selling refurbished laptops running Libreboot: https://minifree.org/ . She's still in business and apparently just set up a new lab :-)

As you say, libreboot is a downstream fork of coreboot (i.e. not the same as coreboot). It's made possible by the fact that there was enough work done in coreboot to enable them to start a business and add value for their customers by making it more libre. That's a great thing IMO and certainly more productive than all the people complaining about the situation using non-libre systems.

[*]No matter what, mainline Linux devs do not accept blob-only code running on main cpu as part of project, release cycle or something endorsed by them.[*]Furthermore, recent kernels splitted most (if not all) firmwares to separate "linux-firmware" project, to decouple further. I warmly welcome this change.

There are no blobs in coreboot, they exist in 3rdparty/ as submodules (additional git repositories on the same server) and imported only if the user enables CONFIG_USE_BLOBS. So in that regard it's similar to linux-firmware, and I don't see anybody demanding that kernel.org add an ugly warning to their homepage, even though linux-firmware is in fact hosted on git.kernel.org.

[*]Linux devs even reluctant to accept opensource (!!!) code if sole user would be some proprietary userspace (hello, ARM GPU).[*]Firmwares in linux kernel run on secondary cpus of peripherals, not main cpu. I can't remember anything comparable to e.g. FSP in mainline Linux.

Linux supports EFI runtime services implemented as proprietary UEFI firmware modules ((https://git.kernel.org/pub/scm/linux...v5.3-rc8#n1937)) and has a ME interface driver (https://www.kernel.org/doc/Documenta...es/mei/mei.txt).

I backed one of first more or less "Linux friendly" SBCs, for example. It wasn't perfect in terms of freedoms... since there're many dimensions as well. Like CAD files, etc. But eventually it became my 1st computer I managed to boot without any unknown blobs in boot sequence. I think its way to go.

Nicely done! And hopefully others can learn from your workflow.

However it would be nice if ppl at least don't downplay the problem of backdoored hardware and honestly state what really going on. Sorry if that upsets you, but I would lie if I tell I understand what coreboot is really up to and what values project shares. So I would still think raised question gets some point.

The values are stated plainly on the homepage ;-) The hard part is achieving them.

One more thing I'll add - coreboot is currently in its 20th year. There was a recent talk about this (videos will be up soon): https://osfc.io/talks/anniversary-keynote. It was made possible by the fact that 20 years ago one could simply go to developer.intel.com and download all the datasheets needed to write a BIOS. It was started because the original author had problems with the BIOS on a cluster of servers in an HPC environment and had no way of auditing the BIOS (important for a machine running in a research lab with classified materials) and couldn't debug or fix issues.

My point is that coreboot predates ME/PSP/FSP/etc. by a long shot. The goal was never to support blobs, those were incidental to the evolution of x86 architecture. The goal, as is currently stated on the homepage, is to provide auditability and maximum control to the user.

[pgeorgi]

I would lie if I tell I understand what coreboot is really up to and what values project shares.

That might be because "the project" has no values to share beyond that its code base is mostly GPLv2 (with some BSD-l stuff on the side). Anything you attempt to derive from that (e.g. assuming that it's FSF aligned, or that it is not. That it aims for security to a degree as Timothy is doing, or not. That there's an idea what precisely constitutes a blob. And so on) is true for a subset of coreboot developers only.

One issue with diverse projects like coreboot is that they're a projection field for lots of different crowds and the hard part is really to avoid that any of them take over and drive out all the others. Hence the opposition to go all-in on any demands.

Such stuff seems to be easier for a project that pretends to have a single, well-defined compass (but usually doesn't. It only gets extra ugly when that illusion breaks down).

[SystemCrasher]

Nobody is claiming that FSP/BinaryPI/ME/PSP/etc. are open-source. If they are, they are wrong. If they are conflating coreboot with those things, they are also wrong, just as they would be wrong by conflating Linux with any of the closed-source drivers and apps that run on it.

Look, as far as I know, e.g. Libreboot appears to be "deblobbed Coreboot". It gained some popularity on these grounds, despite whole project being just like few scripts to deblob coreboot rather than some major "system works", if I got it right. So there was demand to ensure it happens this way, no?

Linux? While there is even comparable "deblob" project (linux-libre), I have to admit...

• No matter what, mainline Linux devs do not accept blob-only code running on main cpu as part of project, release cycle or something endorsed by them. They are (and always were) hostile to proprietary drivers (up to "fuck you Nvidia" and ton of explicit GPL_ONLY features to discourage it). Sure, users can do whatever, but kernel marks self "tainted" if you load blob. Linux devs made it pretty clear they don't consider self in charge of franken-kernels and actively discourage that.
• Linux devs even reluctant to accept opensource (!!!) code if sole user would be some proprietary userspace (hello, ARM GPU).
• Firmwares in linux kernel run on secondary cpus of peripherals, not main cpu. I can't remember anything comparable to e.g. FSP in mainline Linux.
• Furthermore, recent kernels splitted most (if not all) firmwares to separate "linux-firmware" project, to decouple further. I warmly welcome this change.

So I know answer for Linux. But not for Coreboot.

It's great if you want to warn others about the blackboxes that exist in their systems, clearly more people should be made aware of this issue with various architectures (not just x86, I've seen plenty of bad ideas in the ARM world too). I just ask that you not cause collateral damage to the very small handful of projects that are making a tangible difference.

Collateral damage is a complicated matter. I've seen worst of the worst things, and yes, they were ARMs. Way before it made to x86. Even way before you likely had chances to face that. I knew many years ago it would eventually come. And yes, these worst fears materialized. But...

• I do not get why asking question and clarification of goals is "collateral damage"?
• If we take a look under different angle, recent x86 HW seems to be badly backdoored, both AMD PSP and Intel ME. Methods to "disable" troublesome parts I've seen were unconvincing at best. Merely asking proprietary junk to pike off ... looks rather naive from system engineering and security points. There is no way to execute own code that would reliably takeover ME or PSP cpu at highest privilege level to ensure it actually behaves, right? Correct me if I'm wrong.
• ARMs do not have something like e.g. FSP to the best of my knowledge. At very most I can imagine ATF, but, ironically, it opensource thing, I can even readily name few SoCs that would let me to run self-built ATF. Can't say the same about ME/PSP stuff.
• ARM quite thoroughly documented how their stuff works, boots and so on. Can't remember comparable docs on, say, Intel ME.

At least I guess loud, clear and honest description of problem and project goals and policies wouldn't hurt. And BIG RED WARNING that coreboot/libreboot can't fully deal with it due to HW design. So overall system attitude, security threats and what one could really expect could be reasonably evaluated in clean and honest manner. Without attempts to downplay or hide problems.

Out of curiosity, have you made any real effort to detach yourself from the ecosystem you describe and contribute to something more libre-friendly?

I backed one of first more or less "Linux friendly" SBCs, for example. It wasn't perfect in terms of freedoms... since there're many dimensions as well. Like CAD files, etc. But eventually it became my 1st computer I managed to boot without any unknown blobs in boot sequence. I think its way to go.

As for detaching... I really like this question! I've been lucky to spot upcoming folly many years ago, and try my best to take evasive actions before it turns really bad on me. Right now none of my workflows depend on proprietary programs or OSes. As example I have more or less "mirror" of my desktop on ARM SBC (=same set of packages and configuration). It works. Why not? The only concern is performance (and 2D-only, but I can live with it if that's the only way). Aa techs advance this problem would correct itself. TBH I don't plan to buy any ME/PSP-enabled PCs for myself. I had enough of this shit. My current PC lacks PSP, and still quite powerful thing. But when it comes to "what's next" I doubt it would be Intel or AMD at all.

I've done a bunch of work in coreboot, and I'm using a libre-friendly RK3399-based Chromebook and a Talos II workstation for personal computing. I get the impression that most people who complain about this stuff and demand that others change are actually just useless hypocrites.

Whoa, quite interesting hardware, should I say. I'm more familiar with allwinners though - and can boot at least some of these 100% blob free. Dubs as backup low-power desktops, just in case. As for demands... erm, I do understand asking Intel or AMD to unfuck their hardware design could be naive XD. However it would be nice if ppl at least don't downplay the problem of backdoored hardware and honestly state what really going on. Sorry if that upsets you, but I would lie if I tell I understand what coreboot is really up to and what values project shares. So I would still think raised question gets some point.

[davidhendricks]

I think we have to call black as black and white as white. And even if we want white but got black it would be wrong idea to claim its actually white just because some nasty proprietary vendor forgot to offer appropriate options.

Nobody is claiming that FSP/BinaryPI/ME/PSP/etc. are open-source. If they are, they are wrong. If they are conflating coreboot with those things, they are also wrong, just as they would be wrong by conflating Linux with any of the closed-source drivers and apps that run on it.

So my personal opinion is that Coreboot should put BIG RED WARINING about e.g. modern Intel x86 systems being irrevocably backdoored, to extent not even coreboot can fully fix it. So people do not have false expectations nobody could ever deliver at their full extent. Intel put great deal to ensure their hardware is treacherous backdored crap. With no real means to get around.

It's great if you want to warn others about the blackboxes that exist in their systems, clearly more people should be made aware of this issue with various architectures (not just x86, I've seen plenty of bad ideas in the ARM world too). I just ask that you not cause collateral damage to the very small handful of projects that are making a tangible difference.

Whatever, treachery and murky intents got no room in open world. People use opensource as safeguard against this attitude. It clearly fails to achieve this point for Intel's x86 to full extent. And even more radical stuff like libreboot can't fix that to its full extent - that's how Intel hardware works, with Intel being topmost authority over system. So at most ME can pretend it got out of the way ... but there is no good way to know it for sure.

Out of curiosity, have you made any real effort to detach yourself from the ecosystem you describe and contribute to something more libre-friendly? I've done a bunch of work in coreboot, and I'm using a libre-friendly RK3399-based Chromebook and a Talos II workstation for personal computing. I get the impression that most people who complain about this stuff and demand that others change are actually just useless hypocrites.

[SystemCrasher]

So your suggestion is... DRM dongles?

Actually its has been there and more or less worked. Someone remembers e.g. HASP keys? Oh sure, as proprietary murky stuff it proven to be crackable. However, I'm aware of far more efficient (but more exotic) approaches that were rather challenging to counter. Though realistically, any DRM/restriction scheme is eventually cracked or worked around if there is good demand. The only reliable thing I know is to run whole app remotely and deny access if person failed to pay, etc. But then it more like "service". Yet, services at least make it clean you don't own it, rather getting some use of it. While more traditional apps and now also hardware can pretend you "buy" something, yet from realistic point it proves to be crappy lease on murky terms, with vendor being topmost authority over what you do (which is odd for "bought" and "owned" things, isn't it?).

So at the end we pay hefty "ownership" price just to find there're plenty of strings attached and it's not up to owner to decide how to use their "property" that proves to have mind of its own. It sucks, isn't it?

[SystemCrasher]

I think we have to call black as black and white as white. And even if we want white but got black it would be wrong idea to claim its actually white just because some nasty proprietary vendor forgot to offer appropriate options. So my personal opinion is that Coreboot should put BIG RED WARINING about e.g. modern Intel x86 systems being irrevocably backdoored, to extent not even coreboot can fully fix it. So people do not have false expectations nobody could ever deliver at their full extent. Intel put great deal to ensure their hardware is treacherous backdored crap. With no real means to get around. Pretending otherwise is misnomer and could put people into dangerous situations where they believed otherwise but it proven to be not a case. Whatever, treachery and murky intents got no room in open world. People use opensource as safeguard against this attitude. It clearly fails to achieve this point for Intel's x86 to full extent. And even more radical stuff like libreboot can't fix that to its full extent - that's how Intel hardware works, with Intel being topmost authority over system. So at most ME can pretend it got out of the way ... but there is no good way to know it for sure.