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

      Working...
      X