Announcement

Collapse
No announcement yet.

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

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • pgeorgi
    replied
    Originally posted by starshipeleven View Post
    The website, wiki and press material still advertises it as if it was opensource when it is mostly not. That's what.
    coreboot is open source. That it uses some non-open services doesn't detract from 100% of the stuff in the coreboot repo being GPLv2 compatible (mostly GPLv2, some GPLv2+, some BSD-l, some other BSD-style licenses, some CC-by).

    Leave a comment:


  • starshipeleven
    replied
    Originally posted by schmidtbag View Post
    Even still - so what?
    The website, wiki and press material still advertises it as if it was opensource when it is mostly not. That's what.

    Yes, Coreboot really is Coreboot. Just because the way it is used doesn't conform to Coreboot's goals, doesn't mean the software suddenly lost sight of its goals.
    Dunno, Coreboot was born to get rid of proprietary firmware and ends up being little more than a wrapper for blobs, requiring NDAs to be ported on any real hardware. That's so far against the original project goals that it isn't even funny.

    You can say "doesn't mean the software suddenly lost sight of its goals", but it's wrong.

    The difference here is Coreboot is open-source.
    No the difference is that Coreboot is not really "Opensource" anymore for x86 and this is worth pointing out on the website.

    This isn't about whining because of Coreboot's current state, it's about being honest about it to the world.
    Last edited by starshipeleven; 09 September 2019, 10:46 AM.

    Leave a comment:


  • pgeorgi
    replied
    Originally posted by starshipeleven View Post
    On Intel platforms the blobs (the FSP) are smart enough to init the whole thing and are also able to load payloads (like say u-boot) on their own. Coreboot is basically a wrapper for that. Also the docs to configure the FSP are available only under NDA.
    Just today we landed a change (by Intel themselves!) that returns some control over hardware init (SPI flash lock registers to be precise) on Cometlake from FSP to coreboot. FSP _can_ do everything (for the poor saps that use FSP in non-coreboot configurations), but in a coreboot configuration it doesn't and that makes coreboot more than "basically a wrapper".

    Reverse engineering efforts done outside Intel get into the tree as soon as they're usable and become the default configuration over "official" binaries (see Ivybridge).

    Originally posted by starshipeleven View Post
    on top of that it's not used much outside of x86.
    >10% of the boards in the coreboot tree are non-x86.

    That makes it still rather x86-focused but it's more diverse than it used to be.

    I really like to see all of that stuff improve: more reverse engineering, more non-x86 hardware, more open source contribution by the silicon vendors themselves. There are things I can't do (reverse engineering while having access to relevant information under NDA has rather bad optics), there are other things I do that aren't very visible (but that I'm quite certain have some positive impact).

    Raptor considers x86 a lost cause and so they moved to Power9. More power to them (pun intended) but due to costs it remains a 1%er solution (while Raptor managed to bring it more into mainstream from the 0.1%er solution it was before, so yay). I'm not so sure that things will remain that open there once it becomes mainstream hardware. As soon as a Netflix client becomes a "hard" requirement for the platform's user base, Power will undergo lockdown attempts as well (and an open ISA won't help: the ISA was never the problem, fab access is). We need systematic solutions to such requests, not just ISA owners that are desperate to increase their marginal slice of market share but will throw you under the bus as soon as things take off.

    I think x86 can be salvaged (not this chip generation, but the general direction) and through x86 and ARM (and their sway on the market, and the vendors, and everything) it might be possible to set healthier trends and standards for the entire industry.

    Leave a comment:


  • schmidtbag
    replied
    Originally posted by starshipeleven View Post
    Yes that's his point.
    His point is having a dysfunctional amount of Coreboot code is enough to qualify as using Coreboot?
    Even still - so what? If a product is advertised as "Coreboot ready" but nothing worth mentioning is actually made from Coreboot, then that's false advertising and you get to sue. If you were hoping it used Coreboot for the sake of modifying it for your needs, well, you should've done more research. If you don't intend to even look at the source code, you won't know the difference, so if the product works as expected, why does it matter how little of it is actually Coreboot?
    If it's all about sticking to principles, well, good luck with that.
    That's more or less what the article is about. The Coreboot website still states the original project goals which are far from the actual reality.
    Nowadays Coreboot is more or less a wrapper for the FSP, what you can do on it without an NDA with Intel is limited because of FSP blobs and their (lack of) documentation, and on top of that it's not used much outside of x86.

    So is Coreboot really Coreboot anymore?
    Yes, Coreboot really is Coreboot. Just because the way it is used doesn't conform to Coreboot's goals, doesn't mean the software suddenly lost sight of its goals. I really don't understand how this is up for debate. Cotton swabs do not exist to clean your ears (in fact, on the box it explicitly says not to do that), yet, that's easily the most common use of them. So, does that mean products like Q-tips need to rebrand themselves as "ear canal cleaners"?

    The difference here is Coreboot is open-source. One of the key benefits to open-sourcing something is so you can modify it to your needs. For people who whine about an open-source tool being mutilated for proprietary needs is ridiculous. That's like giving an angsty teenager a can of spray paint and putting him in front of a brick wall with no surveillance and getting upset that he vandalized it.

    As the saying goes, "this is why we can't have nice things".

    Leave a comment:


  • starshipeleven
    replied
    Originally posted by schmidtbag View Post
    Have you? Because even taking into account you're exaggerating, 10 lines of code for a crucial platform like Coreboot isn't going to do anything.
    Yes that's his point.

    On Intel platforms the blobs (the FSP) are smart enough to init the whole thing and are also able to load payloads (like say u-boot) on their own. Coreboot is basically a wrapper for that. Also the docs to configure the FSP are available only under NDA.

    On most modern AMD stuff you can't run shit with Coreboot because they don't release the AGESA (and documentation) for them.

    Is it really Coreboot anymore if you're using that little of it?
    That's more or less what the article is about. The Coreboot website still states the original project goals which are far from the actual reality.
    Nowadays Coreboot is more or less a wrapper for the FSP, what you can do on it without an NDA with Intel is limited because of FSP blobs and their (lack of) documentation, and on top of that it's not used much outside of x86.

    So is Coreboot really Coreboot anymore?
    Last edited by starshipeleven; 09 September 2019, 09:31 AM.

    Leave a comment:


  • schmidtbag
    replied
    Originally posted by madscientist159 View Post
    Cool! Lets say I've got a set top box here that uses 10 lines of coreboot to load a DRM enforcing OS. The megabytes of vendor firmware before it, and the gigabyte of vendor binaries after it, are signed, locked, and encrypted. I can look at those 10 lines of code, but not touch.

    Would you choose this set top box over a cheaper, fully proprietary model just because of those 10 lines of open source?
    Yes, because I'm not a Stallmanite and 99% of the media I'd be consuming on the set top box doesn't comply with open-source standards anyway.
    So riddle me this:
    Is it really Coreboot anymore if you're using that little of it?
    Have you actually looked at the ratio of open code to vendor binaries in coreboot for modern platforms, including the ME/PSP and microcode?
    Have you? Because even taking into account you're exaggerating, 10 lines of code for a crucial platform like Coreboot isn't going to do anything.

    Leave a comment:


  • pgeorgi
    replied
    Originally posted by aaahaaap View Post
    Why not? It is false advertising.
    That's _one_ opinion (and that difference in opinion is the source of contention here). Since coreboot leadership disagrees and they're ultimately the ones deciding what changes are made to the frontpage, screaming louder won't change a things - except...

    Originally posted by aaahaaap View Post
    If not at the very least the honest thing to do would be to update the description.
    The conduct shown in this debate isn't conductive for promoting change. If anything, the way this demand was brought up only ensures that nothing will change.

    For people trying to shape the politics of software freedom, politics certainly isn't the strong point of many of the folks involved.

    Originally posted by aaahaaap View Post
    Hopefully it triggers the coreboot devs to go back to the original goals and reject/remove things that are in conflict with it or move those into a separate project.
    We could have done that in the 2009 time frame. The result would have been that in 2019 (as in: now) there would have been 0 lines of open source code that are actually usable by folks. Tianocore would probably exist like it does now, but with no chance for device owners to actually customize it on their device.

    There are lots of dealings with hardware vendors behind the scenes, and it's a constant struggle. We're now in a position that silicon vendors are trying to work within the open source firmware environment, a notable change over the last 10 years. From here, we can (and do) put pressure on vendors to open up more parts, while there's usually back pressure to close down more (that we have to push back against).

    This kind of conversation (and struggle) will end the moment we stop working with them at all "until our demands are met": they won't be met, and they have hardware to sell. Instead, silicon vendors will immediately go back to the scheme they know: send blobs (and sometimes sources) to IBVs who sell shitty code + services to clean it up to OEMs, and a "security model" that's based on "if nobody can modify it, the device is secure".

    However, what these kind of discussion does is: you spend a minute on presenting your case (like dozens other folks: I haven't seen a single new argument on the "firmware freedom" topic in the last 5 years). Each of these minutes cost: 1 minute to engage with you. 1 more minute to deal with silicon vendors engineers (who are usually sympathetic to open source firmware but aren't the ones who decide product direction) who complain (sometimes appropriately) about the hostility in the community. 1 more minute to deal with interested devs who are put off by the bickering (twice, because the dev is also not contributing to a better firmware situation, but considering their options). And finally 3-5 minutes to keep the various factions from warring each other: The question what constitutes an objectionable blob isn't answered the same way by various people. The People's Front of Firmware Freedom sometimes seems even more discontent with the Firmware Freedom People's Front than with the blob-shipping silicon vendor (and vice-versa).

    So, present your case. But also consider please if your contribution is actually original or if it merely reiterates some ancient point, where every minute of you writing something wastes some 8 minutes that could be better spent lobbying silicon vendors to do better.

    Leave a comment:


  • Th3Fanbus
    replied
    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

    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/

    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!

    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

    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.

    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.

    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?

    Leave a comment:


  • aaahaaap
    replied
    Originally posted by Terrablit View Post
    Coreboot has had the same goals and same mission for two decades, now. Just because vendors get in the way of the ideal implementation doesn't mean we need to get on their asses about how it's "false advertising".
    Why not? It is false advertising.
    Hopefully it triggers the coreboot devs to go back to the original goals and reject/remove things that are in conflict with it or move those into a separate project.
    If not at the very least the honest thing to do would be to update the description.

    Leave a comment:


  • Terrablit
    replied
    Originally posted by pgeorgi View Post
    I understood Terrablit to refer to stuff like Lenovo's Wifi adapter whitelist, and those definitely aren't part of BinaryPI or FSP. What kind of whitelist are you thinking of, because I'm not aware of any in either binary.
    Originally posted by madscientist159 View Post
    I understood the whitelist comment to be more related to AMD's recent disabling of Gen 4 capability on specific boards. Either way it's hard to argue functionality like a whitelist wouldn't be moved into vendor blob(s) over time.
    Pgeorgi is correct. The comment about blocklists was explicitly around OEM vendors disabling hardware that's not in pre-approved lists maintained in the firmware, which was (and may still be) an extremely common OEM practice with laptops. Dell, Lenovo, HP, etc - all of them had models at one point in time that prevented booting with unrecognized hardware. I've got one from 2008 that does this. Some desktops did it, too.

    This type of functionality usually isn't inside the blobs that are tied to the chipset and CPU. They're usually compiled tables or EFI/BIOS modules, but they're a lot easier to find than those, and can usually be removed without much issue. Drop the table or module, remove the reference that called it during initialization. Vendors could be smart about it and hide it in unrelated code, but they can't hide it in microcode blobs and stuff like that where Intel/AMD don't give them the source.

    BIOS modding communities used to do this sort of thing, as well as other things like enabling Virtualization support options that weren't displayed in vendor firmware (as was common on Sony VAIO laptops when VT-x/VT-d was new) or removing vendor limitations (like when some laptops limited the SATA ports to a lower speed than the hardware supports), or fixing bad ACPI tables that were ignored in Windows but broke Linux. Sloppy vendor "customizations" cause no end of grief to Linux.

    Having an open-source firmware framework that loads blobs means you can work around issues from the motherboard vendors - ASRock, MSI, Lenovo, Asus, etc - a lot easier. The necessary blobs are related to the chipset and CPU, and most of that is exactly the same for the same chipset. We have far more functionality problems from the motherboard vendors than we do from the CPU vendors. We can lean on the CPU vendors directly to have a way to disable security co-processors. And we have to do that anyway. Motherboard vendors just don't care if things are broken.

    And, as stated, if we can support chipsets, that'll add preliminary support for multiple boards that use them, and make collaboration easier on reverse engineering the blobs. Some hardware is even shared across chipsets.

    Originally posted by madscientist159 View Post
    As a native English speaker this is not clear that "maximum control" means "maximum possible control within vendor-imposed hard limits". In fact it sounds like if I use coreboot I get complete and full control of the hardware I'm using coreboot on.
    EDIT: Do you think that "maximum control" will turn you into a God when you install Coreboot? Will it grant you the power to create and destroy worlds, to dominate the markets and turn lead to gold? Will it let you store the number 257 in a byte? No. There's always an implied limit. It's up to the reader to figure out what the maximum is, and not start a cult around unfettered "maximum control." You wouldn't even know you're not getting "maximum control" until you read enough to understand why you can't get it.

    Literally no one with any background knowledge has had this expectation since motherboard BIOSes became flashable and CPUs started having microcode patches. It might have passed the halfway point of the x86 platform. Meaning it's been this way most of the time x86 has been dominant. And x86 has set the expectations, so there's no need to be pointing out x86's "unique situation". Because it's the situation of 90% of available computing hardware. Fully FOSS booting is just gaining momentum withthe new focus on security, and it's not anyone's expectation who knows anything when they look up random hardware.

    Coreboot isn't marketed to grandpas, toddlers and basket weavers. If you're looking into BIOS replacement in the first place, you should understand the underlying technologies. The information is on the Coreboot pages, just not front and center. If you flash your motherboard to Coreboot without RTFMing, you deserve any and all problems you get.

    Domain terminology overrides native English expectations. Computers and firmware have words and phrases specific to them. No one reasonable sets their viewpoint on a product based on the frontpage blurb. If you don't get the background information to understand the product, you shouldn't be the decider. Otherwise we'd have to fill the frontpage with idiot caveats telling people to not swallow coreboot, and that coreboot is not intended for anyone under 12 years of age, and that coreboot might eat your babies.

    Coreboot has had the same goals and same mission for two decades, now. Just because vendors get in the way of the ideal implementation doesn't mean we need to get on their asses about how it's "false advertising".
    Last edited by Terrablit; 09 September 2019, 05:10 AM.

    Leave a comment:

Working...
X