Announcement

Collapse
No announcement yet.

GNU Linux-libre 5.10-gnu After A Busy Time Deblobbing

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

  • GNU Linux-libre 5.10-gnu After A Busy Time Deblobbing

    Phoronix: GNU Linux-libre 5.10-gnu After A Busy Time Deblobbing

    Following yesterday's release of the Linux 5.10 LTS kernel the GNU folks have released their "GNU Linux-libre 5.10-gnu" downstream that is the Linux kernel but without support for loading proprietary modules as well as preventing closed-source firmware binaries from being loaded on the system and related steps in the name of free software...

    http://www.phoronix.com/scan.php?pag...nux-Libre-5.10

  • #2
    So last time I went to Dell support, there were at least 4 or 5 firmware updates available for my desktop system, BIOS, SSD, RAID, Bluetooth ... So why does the PureOS with it's GNU Linux-libre fully support hardware like mine but not work on systems that have this firmware in RAM instead? Why is a blob in RAM so terrible but a blob in EPROM AOK? Why penalize people who bought BT with FW on RAM and still support premium cards like mine? What is gained?
    Last edited by slacka; 14 December 2020, 11:13 AM.

    Comment


    • #3
      The Linux kernel became a nest for blobs...

      Comment


      • #4
        Originally posted by slacka View Post
        So last time I went to Dell support, there were at least 4 or 5 firmware updates available for my desktop system, BIOS, SSD, RAID, Bluetooth ... So why does the PureOS with it's GNU Linux-libre fully support hardware like mine but not work on systems that have this firmware in RAM instead? Why is a blob in RAM so terrible but a blob in EPROM AOK? Why penalize people who bought BT with FW on RAM and still support premium cards like mine? What is gained?
        I don't understand you. What's your case ? Do you have a system with upgradeable blobs in EPROM that you upgrade from BIOS, EUFI, some bootloader or booting a different operating system, and then you load linux-libre on this system ? If so then linux-libre is not loading the firmware, so it can hardly avoid to run there. Do you think it should carry a blacklist of hardware it refuses to run on ? But if this is the case I don't understand why do you want to run linux-libre and then upgrade those blobs. I run linux libre because I don't want to run blobs inadvertently, but then of course I don't update any firmware by means outside linux-libre. It would be selfdefeating, so I don't understand why you would do it.

        Or do you mean that linux-libre will take blobs and update them to EPROM but not run them from RAM ? That's not how I understand linux-libre to work.

        If you mean what's the difference between blobs in ROM (not upgradeable) and blobs in RAM or EPROM (upgradeable) then it's basically that any code that can be updated should be free, and code that can not be update is in practice hardware (that should ideally also be free and open, but at least is fixed). But once code can be changed, then it should be changeable by all users, so you should have source, free build chain, rights and upgrade means, not only your vendor (and its government, its attackers, its deserting employees or any corporations that buys it later).

        Sorry if I'm thick today or something. I didn't understand your question.

        Comment


        • #5
          The crux of my Q is why is my Bluetooth adapter with EPROM blob supported while other Bt adapters with blobs in RAM not supported?

          Originally posted by phoron View Post
          I don't update any firmware by means outside linux-libre. It would be selfdefeating

          You telling me I was somehow better of not updating my firmware? Or an older Bt card with original firmware is better than a version produced later with the newer firmware? How do you know the newer is worse than the older? What about CPU microcode? I take it you don't run Intel or AMD CPUs?

          Comment


          • #6
            Originally posted by slacka View Post
            The crux of my Q is why is my Bluetooth adapter with EPROM blob supported while other Bt adapters with blobs in RAM not supported?




            You telling me I was somehow better of not updating my firmware? Or an older Bt card with original firmware is better than a version produced later with the newer firmware? How do you know the newer is worse than the older? What about CPU microcode? I take it you don't run Intel or AMD CPUs?
            I don't know about your Bluetooth adapter. It has a blob that you upgrade how? If it is not linux-libre that is doing the updating, but some user-space program, or some other OS, then maybe linux-libre can't do anything about it ? If it's linux-libre, maybe its something they haven't deblobed yet ?

            I tell you you're better off not using hardware that needs firmware updates. But I don't care what you use. I was just surprised that you want to upgrade blobs and at the same time choose linux-libre. It's like using the console for gestures or looking for libreoffice in Stream. Not like that was a crime or anything, just that I can't think why.

            How do you know the new blob is better than the old ? It's still opaque.

            I don't use Intel or AMD CPUS currently, I have a feeling that only Intel and AMD use them. Their customers pay for CPUs that keep running what Intel and AMD decides. But avoiding all blobs is difficult. I think there's still one in my ethernet adapter. I'll upgrade it when there's free firmware for it.

            Comment


            • #7
              Got it running on my Trisquel system i'm typing this from. Working good so far.
              Last edited by PublicNuisance; 14 December 2020, 02:22 PM. Reason: typo

              Comment


              • #8
                Originally posted by slacka View Post
                The crux of my Q is why is my Bluetooth adapter with EPROM blob supported while other Bt adapters with blobs in RAM not supported?
                Because that is the line that they decided to draw?

                It is their right to draw lines, and not step over them for their community.

                The pragmatic reality says that in order to boot pretty much any recent system one has realize that the CPU itself contains non-free firmware, so the line is drawn carefully because people do not wish to go back to using stone knives and bear skins to write their code.

                Comment


                • #9
                  My understanding is that is a little bit similar to the goals stated on the 2nd slide here:

                  https://www.openbsd.org/papers/eurob...ce-drivers.pdf

                  If the closed-source firmware is already on the eprom, thats fine. What the Linux libre guys do not want to do though is have to distribute non-free firmware. If you already have it baked into everything you own, that is your problem I suppose.

                  Originally posted by slacka View Post
                  You telling me I was somehow better of not updating my firmware? Or an older Bt card with original firmware is better than a version produced later with the newer firmware? How do you know the newer is worse than the older? What about CPU microcode? I take it you don't run Intel or AMD CPUs?
                  In many cases, yes. Older is better. The older firmware gives you more freedom. Think jail breaks on games consoles or phones. Usually if you cannot downgrade firmware, these non-updated devices are actually much more valuable to hardware enthusiasts.
                  Chasing version numbers isn't always a good use of your time in more ways than one!

                  My advice is to do your own research if you ever need to make permanent changes to your belongings.
                  Last edited by kpedersen; 14 December 2020, 05:46 PM.

                  Comment


                  • #10
                    Originally posted by kpedersen View Post
                    If the closed-source firmware is already on the eprom, thats fine. What the Linux libre guys do not want to do though is have to distribute non-free firmware. If you already have it baked into everything you own, that is your problem I suppose.
                    This is where things get horrible. Nothing says that the backed in firmware is any good. Wifi it is a case that the old firmware can in some countries have you broadcasting on wrong frequencies this can be a quite a fine for radio interference. So there are cases where old firmware is bad

                    Originally posted by kpedersen View Post
                    In many cases, yes. Older is better. The older firmware gives you more freedom. Think jail breaks on games consoles or phones. Usually if you cannot downgrade firmware, these non-updated devices are actually much more valuable to hardware enthusiasts.
                    Chasing version numbers isn't always a good use of your time in more ways than one!
                    The firmware blobs Linux kernel loads do not go into eprom also none of them have any restriction against downgrading.

                    Originally posted by kpedersen View Post
                    My advice is to do your own research if you ever need to make permanent changes to your belongings.
                    This is the big problem. Items like wifi and bluetooth cards to deal with regulation changes at times will need to change the firmware. If that firmware is stored in a eeprom every time you change it this is a permanent change that risks bricking the device.

                    The allowing the OS to load the device firmware into a ram on the card/device reduces hardware bricking risk.

                    closed-source firmware binaries<< This bit from the libre guys really does not make sense. From a security point of view old firmware in eeprom on the card and loading old closed-source firmware binaries from the OS provides the same security risks. Big problems is how to safely be updating that firmware. Taking the eeprom off the card and replacing it with ram then require the OS to send the firmware blob when the device its inited is a good way to-do this for cards that need newer firmware more often so not to brick them.

                    Blocking loading closed source drivers in kernel space makes sense like the Nvidia binary blob. Going after hardware that has been designed from the ground up to have the firmware as open source as possible also makes sense.

                    Please note libre deblobing have broken some of those in the past that have open source firmware for their devices of course these are devices that need the driver to provide the firmware.

                    Of course the downside of ram storage of device firmware instead of on the device eeprom means OS need to ship around more firmware blobs so they work. This is a trade off like it or not.

                    Comment

                    Working...
                    X