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

  • #61
    Originally posted by madscientist159 View Post
    That being said my contention would be that coreboot should also work to replace the EC code in such situations; this is an area where Google sets a good example with the Chromebook EC code.
    And ChromeEC also isn't coreboot, in case it wasn't already obvious.

    Originally posted by madscientist159 View Post
    RISC-V always had issues with this. As was said once to me, the easiest way to get a RISC-V CPU is to buy an NVIDIA GPU. It's meaningless in terms of doing anything with it aside from running NVIDIA signed firmware, but it's a RISC-V CPU nonetheless. I'm not surprised at all given its positioning in the market that it will tend to sell well for DRM applications.
    That's a bummer. So I guess your next crusade will be to go around to RISC-V websites and demand that they remove any mention about freedom and openness since RISC-V can be used in non-libre systems.

    Originally posted by madscientist159 View Post
    That being said, as an open ISA there is absolutely nothing stopping the smaller scale manufacture of decent RISC-V chips that are aimed at DRM-free compute
    True, but only if they can deliver something that meets a lot of other non-firmware related requirements. Sadly (but understandably) a lot of people are willing to trade freedom for software compatibility (x86 vs non-x86 and ability to do stuff like watch Netflix or Amazon videos), an aluminum chassis, backlit keyboard, some extra battery life, a nice touchpad or display, or just to save a few bucks. From what I've seen so far the RISC-V folks have many years to go before anyone will consider carrying a general-purpose RISC-V system with them. (I'm speaking from years in the laptop business, I'm guessing you get some similarly frustrating complaints on the POWER9 side of things)

    Originally posted by madscientist159 View Post
    Frame challenge: why do you assume Netflix DRM has to be in the CPU? In fact why does Netflix DRM have to have access to customer data period? The absolute safest, less breakable way to do Netflix DRM is to point the encrypted data stream at a Netflix compatible GPU and tell it where to render. Let us have our CPUs for our own use.
    So your suggestion is... DRM dongles?

    Anyway, I assume it's for economic reasons. Integrated devices are usually cheaper than add-on devices, and most of the DRM stuff is for embedded/mobile platforms that are extremely cost-sensitive to begin with.
    Last edited by davidhendricks; 10 September 2019, 01:27 AM.

    Comment


    • #62
      Originally posted by davidhendricks View Post
      That's a bummer. So I guess your next crusade will be to go around to RISC-V websites and demand that they remove any mention about freedom and openness since RISC-V can be used in non-libre systems.
      No. And fundamentally that's a significant oversimplification of my current issue with the coreboot website. The RISC-V site ( https://riscv.org/ ) makes no claims beyond an open ISA, it doesn't go on about control over technology and similar things. It clearly states what RISC-V is. My takeaway from it is that I have the freedom to implement cores and emulators, not that I can just take something off the shelf and get control of it.

      Originally posted by davidhendricks View Post
      True, but only if they can deliver something that meets a lot of other non-firmware related requirements. Sadly (but understandably) a lot of people are willing to trade freedom for software compatibility (x86 vs non-x86 and ability to do stuff like watch Netflix or Amazon videos), an aluminum chassis, backlit keyboard, some extra battery life, a nice touchpad or display, or just to save a few bucks. From what I've seen so far the RISC-V folks have many years to go before anyone will consider carrying a general-purpose RISC-V system with them. (I'm speaking from years in the laptop business, I'm guessing you get some similarly frustrating complaints on the POWER9 side of things)
      Interestingly we continue to have high interest in DRM-free POWER laptops. And the customer base understands no Netflix etc. -- they already have cheap set top box players, game consoles, or phones for that kind of thing, and want the DRM functions off their personal or corporate general purpose computers.

      Originally posted by davidhendricks View Post
      So your suggestion is... DRM dongles?

      Anyway, I assume it's for economic reasons. Integrated devices are usually cheaper than add-on devices, and most of the DRM stuff is for embedded/mobile platforms that are extremely cost-sensitive to begin with.
      But I'm not saying dongle, am I? I'm saying a small modification to the GPU firmware (i.e. the PSP in the GPU for AMD GPUs) to manage the Netflix keys and decrypt the video all on the GPU SoC. The DRM provider doesn't get access to the CPU, the consumer doesn't get access to the video stream, and everyone wins with no extra hardware cost at all.

      Comment


      • #63
        Originally posted by madscientist159 View Post
        But I'm not saying dongle, am I? I'm saying a small modification to the GPU firmware (i.e. the PSP in the GPU for AMD GPUs) to manage the Netflix keys and decrypt the video all on the GPU SoC. The DRM provider doesn't get access to the CPU, the consumer doesn't get access to the video stream, and everyone wins with no extra hardware cost at all.
        No matter what the approach, they need a customer (ideally with a $$$ project as a force multiplier) who makes such requests. Only then will they start to care about it. And that's precisely why it's important that _some_ folks keep up that conversation, and that requires compromise. And if x86 moves in that direction, everybody will follow.

        As an aside: we're talking about SoC level hardware where the GPU is integrated. Traditionally IOMMUs aren't fully effective in such hardware (because latency!!!11), so you're back to Netflix DRM code affecting the entire system.

        Comment


        • #64
          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.
          Last edited by SystemCrasher; 11 September 2019, 03:27 AM.

          Comment


          • #65
            Originally posted by davidhendricks View Post
            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?
            Last edited by SystemCrasher; 11 September 2019, 03:38 AM.

            Comment


            • #66
              Originally posted by SystemCrasher View Post
              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.

              Originally posted by SystemCrasher View Post
              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.

              Originally posted by SystemCrasher View Post
              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.
              Last edited by davidhendricks; 12 September 2019, 01:11 AM.

              Comment


              • #67
                Originally posted by davidhendricks View Post
                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.
                Last edited by SystemCrasher; 12 September 2019, 08:23 AM.

                Comment


                • #68
                  Originally posted by SystemCrasher View Post
                  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).

                  Comment


                  • #69
                    Originally posted by SystemCrasher View Post
                    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.

                    Originally posted by SystemCrasher View Post
                    [*]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.
                    Last edited by davidhendricks; 13 September 2019, 12:16 AM.

                    Comment


                    • #70
                      Originally posted by pgeorgi View Post
                      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!

                      Comment

                      Working...
                      X