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

  • #71
    Originally posted by davidhendricks View Post
    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.
    Last edited by SystemCrasher; 09-20-2019, 02:11 PM.

    Comment


    • #72
      Originally posted by SystemCrasher View Post
      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.
      Last edited by pgeorgi; 09-24-2019, 04:07 AM.

      Comment


      • #73
        Originally posted by pgeorgi View Post
        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.
        Last edited by SystemCrasher; 11-15-2019, 05:52 PM.

        Comment

        Working...
        X