Announcement

Collapse
No announcement yet.

GNU Linux-libre 5.3 Continues Deblobbing & Dealing With Firmware Trickery

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

  • #11
    Originally posted by andyprough View Post
    So no one should do anything to move towards increased freedom because reasons.
    no. no one should claim that moving away from increased security with no change in freedom is "increased freedom".

    Comment


    • #12
      Originally posted by hotaru View Post
      no. no one should claim that moving away from increased security with no change in freedom is "increased freedom".
      So no one should work on any project to free any aspect of the hardware or software because there will always be another and another bit of firmware somewhere that doesn't allow itself to be freed. There really should be no advancements at all toward freedom until the entire stack top to bottom can be freed up all at once magically. Which of course will never happen, and since the incremental steps aren't taken then a truly free system will only ever be an impossible dream.

      And oh by the way, you should talk to one of those libreboot neck beards sometime who has dealt with all the issues a few thousand times. Those black box microcode updates aren't always really updates at all. Very possibly the microcode your laptop is born with is the same microcode it will die with ten years later, regardless of your belief that Intel is constantly improving your security. There's a reason it's a black box.

      Comment


      • #13
        Originally posted by andyprough View Post
        So no one should work on any project to free any aspect of the hardware or software because there will always be another and another bit of firmware somewhere that doesn't allow itself to be freed.
        you're missing the point. what linux libre is offering here isn't "don't run a binary blob" as an alternative to "run a binary blob". it's "run a binary blob with known bugs (including security vulnerabilities)" as an alternative to "run a binary blob that has at least some chance of being ok". it does not free any aspect of the hardware or software at all.

        Comment


        • #14
          Originally posted by hotaru View Post
          you're missing the point. what linux libre is offering here isn't "don't run a binary blob" as an alternative to "run a binary blob". it's "run a binary blob with known bugs (including security vulnerabilities)" as an alternative to "run a binary blob that has at least some chance of being ok". it does not free any aspect of the hardware or software at all.
          You think you are the first one that's ever thought of this but you aren't. Far from it. Talk to some of the folks that actually work on coreboot and libreboot and linux-libre and you may find that some of your assumptions are based on missing or incorrect information. I've talked to them on this very issue and the matter is not nearly as cut and dry as you make it out to be. Black box firmware and microcode and whether or not they actually receive true updates and the value of those updates is a very very deep rabbit hole and much of what is promoted to the general public is either blatantly false or at best intentionally deceptive. And trust me, there's nothing that bothers a libre-linux dev or libreboot dev more than the fact that there's firmware that still can't be trusted. Which is why projects such as Talos are so exciting, as you've pointed out.

          Comment


          • #15
            Originally posted by andyprough View Post
            So no one should do anything to move towards increased freedom because reasons. Because you say so. Makes sense. I'll tell everyone to give up their projects and install Windows 10. Or buy Macs.
            I did not write that at all. I am not past moving to more freedom and accountability. There is no need to deceive yourself in the process. If you have to run a blob you should be using the most secure version you can.

            Problem I have is items like ME and Wifi running old versions of their firmware it increased freedom to anyone wanting to remotely hack your system. This is not the kind of freedom we want in most cases.

            Originally posted by andyprough View Post
            I guess you've never thought for a moment that you would have zero non-proprietary options if there weren't these crazed neck beards sitting in their basements working on these incremental hardware and software freedom projects since Stallman was writing emacs and the GNU tools at MIT in the 70s. A lot of the advances you take for granted are because of those crazed neck beards. There would be no GNU/Linux systems if your viewpoint had been predominant.
            When those crazed neck beards started they piece by piece made replacements to the Unix parts. This was not them stop using closed source parts but systematically replace those parts. This is totally different to we will not load blobs. Early would be more we will reverse and replace the blobs with something we understand.

            Systematic replacement process makes sure you don't end up more insecure in the middle.

            The reality in x86 cpus we have zero options to boot without binary blobs these days. Intel and AMD both require there large blobs of stuff so their cpu start up,

            We do really need to start considering our buying choices.

            My view is in fact in alignment with the actions at the start of the GNU to replace UNIX backing process of systematic replacement and truthfulness of how deep in the hole we are. Disabling loading blobs only to have the EFI/bios put blobs in does not change the volume of closed source you are in fact using or how far your freedom is screwed.

            I really want true progress report on how far freedom is this does mean mapping out all closed source firmware used and the different level of security risk.

            Comment


            • #16
              Originally posted by andyprough View Post
              Talk to some of the folks that actually work on coreboot and libreboot and linux-libre and you may find that some of your assumptions are based on missing or incorrect information.
              as someone working on reverse engineering closed source firmware, I have talked to coreboot and libreboot developers and found them to be very disinterested in actually improving the situation with firmware blobs at all.

              Comment


              • #17
                Originally posted by andyprough View Post
                And trust me, there's nothing that bothers a libre-linux dev or libreboot dev more than the fact that there's firmware that still can't be trusted.
                This is my problem. Blocking loading firmware blobs in fact horrible end up having to trust the default loaded firmware that can in fact be known to be insecure.

                Yes they don't like that there if firmware that cannot be trusted but they end up doing things setting up any user to follow their path to possible use not just fireware of questionable quality but firmware that is know to be security breached.

                Dealing with closed source firmware blobs best is replacement next best is loading a intentionally made disable like ME cleaner makes. ME cleaner still requiring loading a blackbox firmware blob just one that is configured to put ME in functionality disabled state.

                Not loading a blob at all and letting some random version default operate is the worst possible outcome for end user security.

                Comment


                • #18
                  Originally posted by hotaru View Post

                  as someone working on reverse engineering closed source firmware, I have talked to coreboot and libreboot developers and found them to be very disinterested in actually improving the situation with firmware blobs at all.
                  Not believable. Not after the many conversations I've had.

                  Comment


                  • #19
                    Originally posted by andyprough View Post
                    Not believable. Not after the many conversations I've had.
                    With coreboot it depends when you were talking to them and who you were talking to.

                    This was not important enough to be transferred to the new coreboot docs in 2017.



                    The reality here is some coreboot and libreboot developers are resigned that particular bits of binary blobs in firmware we will not get for x86.

                    x86 we are kind of stuck.

                    Comment


                    • #20
                      Originally posted by oiaohm View Post
                      Either do it fully or not at all. There are platforms where all of the firmware is in fact open source be it the kernel loaded or the default in the hardware.
                      I would disagree on that. Sometimes we want at least loadable, updateable parts to be crystal clear and shit-free - both licensing and actual intentions. And I think the point is not about "not to do it at all" - but rather "hey, we need unscrew our hardware as well!!!". So you completely missed the point... are you some windows/mac "consumer" who doesn't really excersizes openrource freedoms, eh?

                      Good thing about mainline kernel though is that it mostly split firmwares on its own. I guess it reduced amount of efforts for mentioned project remarkably, but as we can see there're always options to improve it. Say I hardly need or want HDCP in my systems. Showcase how to get rid of this folly is therefore something good for me.
                      Last edited by SystemCrasher; 20 September 2019, 04:10 PM.

                      Comment

                      Working...
                      X