Announcement

Collapse
No announcement yet.

NVIDIA Linux Driver Hack Gives You Root Access

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

  • #16
    Originally posted by ssam View Post
    But the FSF are happy with closed code that is burnt onto a ROM (note their advice to the openmoko project to do that). Now if the Nvidia drive came in a ROM on the card, then the FSF would be happy to use it, but any problems like this would be unfixable.

    personally i happily use the opensource drivers for my intel and amd cards.
    That would be one huge ROM. Have you checked how big the blobs are nowadays?

    Comment


    • #17
      yes in the openmoko case it would have been about 1MB, judging by the debian packages size. ( https://www.fsf.org/blogs/community/task2-openmoko ). I wonder if they would accept NAND chip if the ability to wrote to it was removed for example by not connecting some pins to the circuit board. putting 1GB of NAND on a graphics card would not do much to the price.

      Comment


      • #18
        Why do people get upset because of this? It supports the "Freeness" cause. Information needs to be free. The NVidia blob makes sure that everybody can be root and therefore gain access to all information.

        This is truly "Free" as in "Libre" rather than "beer". What the hell do you people want?

        Comment


        • #19
          Originally posted by RealNC View Post
          Why do people get upset because of this? It supports the "Freeness" cause. Information needs to be free. The NVidia blob makes sure that everybody can be root and therefore gain access to all information.

          This is truly "Free" as in "Libre" rather than "beer". What the hell do you people want?
          :-) freedom freedom *waves a flag*

          Comment


          • #20
            Originally posted by ssam View Post
            But the FSF are happy with closed code that is burnt onto a ROM (note their advice to the openmoko project to do that). Now if the Nvidia drive came in a ROM on the card, then the FSF would be happy to use it, but any problems like this would be unfixable.
            There is actually a huge difference between that and blob drivers. The problem with blob drivers is that they offer the potential for kernel compromise. With a bad chunk of firmware, the firmware itself is restricted to the device on which it is loaded. The kernel still needs some kind of driver to interface with the hardware/blobfirmware, hence that kernel driver protects the kernel from the bad blob firmware.

            At least to some degree.


            Think of it like this;
            The chip itself on the device is some kind of undocumented magic box. What difference does it make if the magic box is entirely physical hardware and no part programmed firmware? You still don't know what its doing.

            Comment


            • #21
              Originally posted by RealNC View Post
              Why do people get upset because of this? It supports the "Freeness" cause. Information needs to be free. The NVidia blob makes sure that everybody can be root and therefore gain access to all information.

              This is truly "Free" as in "Libre" rather than "beer". What the hell do you people want?
              Free beer.

              Comment


              • #22
                Originally posted by droidhacker View Post
                There is actually a huge difference between that and blob drivers. The problem with blob drivers is that they offer the potential for kernel compromise. With a bad chunk of firmware, the firmware itself is restricted to the device on which it is loaded. The kernel still needs some kind of driver to interface with the hardware/blobfirmware, hence that kernel driver protects the kernel from the bad blob firmware.

                At least to some degree.
                I suspect a malicious graphics card could do a lot of bad even with a open driver in the kernel. at the very least it could capture private information from the display, but possible also read and inject things in main RAM or on the PCI bus. I suspect thats what you mean by "At least to some degree".


                Originally posted by droidhacker View Post
                Think of it like this;
                The chip itself on the device is some kind of undocumented magic box. What difference does it make if the magic box is entirely physical hardware and no part programmed firmware? You still don't know what its doing.
                I strongly agree. openness/freeness is better, whether its software, hardware or the murky area between.

                Comment


                • #23
                  Originally posted by ssam View Post
                  I suspect a malicious graphics card could do a lot of bad even with a open driver in the kernel. at the very least it could capture private information from the display, but possible also read and inject things in main RAM or on the PCI bus.
                  WebGL is calling..? Some Browsers use sandbox-like approaches AFAIK,
                  but how safe can that be as command streams need to be passed to a kernel component?

                  Comment


                  • #24
                    Originally posted by entropy View Post
                    WebGL is calling..? Some Browsers use sandbox-like approaches AFAIK,
                    but how safe can that be as command streams need to be passed to a kernel component?
                    By now it is a problem, but with future platform we will see widespread IOMMU support and will be able to write graphics drivers that actually limit what GPUs are allowed to do, while interacting with the rest of the system. We will get to a point where GPUs are equally secure as CPUs: total context isolation between processes, but you can always bypass hardware security by exploiting faulty software. But at least hardware exploitability will go away.

                    Comment


                    • #25
                      ROM safer than software? not anymore

                      Originally posted by ssam View Post
                      But the FSF are happy with closed code that is burnt onto a ROM (note their advice to the openmoko project to do that). Now if the Nvidia drive came in a ROM on the card, then the FSF would be happy to use it, but any problems like this would be unfixable.

                      personally i happily use the opensource drivers for my intel and amd cards.
                      But gfx card (not only) with ROM based driver can infect BIOS during cold boot - a computer infection that can never be cured

                      So no go for that.

                      Comment


                      • #26
                        Originally posted by droidhacker View Post
                        There is actually a huge difference between that and blob drivers. The problem with blob drivers is that they offer the potential for kernel compromise. With a bad chunk of firmware, the firmware itself is restricted to the device on which it is loaded. The kernel still needs some kind of driver to interface with the hardware/blobfirmware, hence that kernel driver protects the kernel from the bad blob firmware.
                        You mean like the rootkit in network card firmware?
                        http://it.slashdot.org/story/10/11/2...d-demonstrated

                        A firmware blob can read/modify any memory region with DMA. No driver is needed at all for this to work.

                        Comment


                        • #27
                          Originally posted by droidhacker View Post
                          There is actually a huge difference between that and blob drivers. The problem with blob drivers is that they offer the potential for kernel compromise.
                          Like the local root exploits of the kernel, which is open source but had these holes for years and no one noticed? :-)

                          Comment

                          Working...
                          X