Announcement

Collapse
No announcement yet.

Nouveau: NVIDIA's New Hardware Is "VERY Open-Source Unfriendly"

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

  • We need someone to produce HW that CAN be opened

    Originally posted by bridgman View Post
    Sanitizing microcode is not the problem -- we would need to have different hardware as well. If we open up sanitized microcode for the Linux market then we're basically providing all the HW info required to easily reverse-engineer the un-sanitized microcode used for other markets.
    What we need is hardware that CAN be opened. There are a lot of small devices out there selling to markets smaller than the Linux market for GPU's. Selling us HW that supports DRM and which we have to reverse engineer gives us an incentive to attack the DRM code while we are at it. Nvidia may pay for that one. I could see their fancy card running with their signed firmware loaded-and another, second layer added just above it that alters the functions of some gates to defeat their DRM. We have the binary code and can open it in a hex editor. We can also examine all inputs vs all outputs do determine equivalent bare hardware with the same published command set. Finally, this combined with binary examination of the firmware could work out what is HW and what is firmware that can be changed.

    A lot of us would settle for a card made from an FGPA to be unrelated to any other card, and unable to keep up with any paid game. Cards have had enough power to play the Linux games for many years, look how well the old (but power hogging) Nvidia Gt9800+ ran on Nouveau with clocks all the way up. Using an FGPA would make the card cheap to make-or someone could offer it as a hobbyist kit to get into a different market and not be expected to be able to play DRM'ed movied and games. Remember, those who object to microcode being kept secret usually also object to paid games and don't subscribe to Netflix, Hulu, etc.

    As I've said before, the way things are going I suspect that whole computers will have to be made from FGPA's just to defeat locked boot in the future. Big servers will always be able to run Linux but might end up locked to RHEL or Ubuntu LTS.

    Until that time, how about independent security audits of the hardware and the microcode, hell of the drivers too under NDA by security experts in mutually opposing camps? From where I sit that is the main objection to secret hardware or firmware, regardless of how loaded. In the meantime, things like watching network activity in Wireshark for packets sent over the Internet to hardware makers is a deterrent to the "phone home" behavior feared by so many of us. Yes, I check this stuff myself. That's how I found out that Ubuntu's flashplugin installer has dependencies that phone home automatically, even if only to the package repo webpage. Another good reason not to use flash...

    Comment


    • Are there any cards so old they predate all the DRM engieering?

      Originally posted by bridgman View Post
      Sanitizing microcode is not the problem -- we would need to have different hardware as well. If we open up sanitized microcode for the Linux market then we're basically providing all the HW info required to easily reverse-engineer the un-sanitized microcode used for other markets.
      Here's a thought: how long ago did the first GPU gain support for any kind of DRM? Cards made in 2001 are still able to run Compiz today, and it only takes OpenGL 2.0 to run Cinnamon or gnome-shell. Next up: was the documentation discarded on 10-15 year old designs or does it still exist? Cards that never supported any kind of digital rights management could presumbly have their microcode and their bare HW instruction sets opened up by simply publishing old documents.

      The cards are still out there, they can be found in old computers and trading on Ebay. A practical limitation assuming no desire to reissue the cards would be the cards would have to have been solid in significant numbers with a PCI-e connection, not AGP. The most "free and open" card would be one with published documentation and which was already manufactured years ago, so no new mining, power consumption, or pollution from its usage so long as it's not one of the big power hogs of its era. There was never a time when it took a 50W GPU to run compiz...

      Comment


      • Originally posted by Luke View Post
        What we need is hardware that CAN be opened.
        Yep, understood. It also means the development costs of the HW can't be shared across markets where DRM is required, which is most but not all markets, but you clearly understand that.

        What we are all struggling with is how to size the market (defined as those willing to trade off functionality for openness) and figure out the right feature set. We made an initial attempt when looking into the idea of a product with microcode in flash ("Peace for Our Tme"). The quantifiable market seemed to be somewhere in the range of 20-30 cards. Everyone agreed it was probably a good bit larger but still nowhere near enough to justify the development costs either as a product or as a marketing gesture.
        Test signature

        Comment


        • Originally posted by Luke View Post
          Here's a thought: how long ago did the first GPU gain support for any kind of DRM? Cards made in 2001 are still able to run Compiz today, and it only takes OpenGL 2.0 to run Cinnamon or gnome-shell. Next up: was the documentation discarded on 10-15 year old designs or does it still exist? Cards that never supported any kind of digital rights management could presumbly have their microcode and their bare HW instruction sets opened up by simply publishing old documents.
          I think Rage 128 was the first chip with HW support for DRM - it came in as part of the IDCT block. The Rage 128 was also the first chip with loadable microcode IIRC.

          R128 was where the hardware started interpreting PM4 packets with a microcoded Command Processor.
          Last edited by bridgman; 05 May 2015, 03:03 PM.
          Test signature

          Comment


          • Maybe with FPGA's we will be able at some point to make the cards ourselves?

            Originally posted by bridgman View Post
            Yep, understood. It also means the development costs of the HW can't be shared across markets where DRM is required, which is most but not all markets, but you clearly understand that.

            What we are all struggling with is how to size the market (defined as those willing to trade off functionality for openness) and figure out the right feature set. We made an initial attempt when looking into the idea of a product with microcode in flash ("Peace for Our Tme"). The quantifiable market seemed to be somewhere in the range of 20-30 cards. Everyone agreed it was probably a good bit larger but still nowhere near enough to justify the development costs either as a product or as a marketing gesture.
            OK, the combined market for FPGA's is the total of all markets for devices too small for dedicated chips. They exist today but seem to be in their infancy. Perhaps someday there will be "generic" PCI-e boards with a socket for a generic FPGA on them that can become ANY extension card? At that point it would become possible to create a video card yourself so long as an analog output was not required. If it was, perhaps that chip too would be one of many options, along with wifi radios, etc that go into a common form factor socket? Ten years ago, Radio Shack would have been the market for such a thing, they were just starting to sell Arduino stuff before they went belly-up. Too bad the ham radio traditions are in such decline!

            This would give a generic extension card defined by it's firmware/software and what is put into the accesory sockets. It could be anything. Performance would not be great but it would not have to be. Like I said, the LibreOS market and the market for DRM'ed games and movies do not overlap as far as I can tell.

            Comment


            • Originally posted by Luke View Post
              Like I said, the LibreOS market and the market for DRM'ed games and movies do not overlap as far as I can tell.
              That's the part I'm less sure about. I do agree that there's probably not a big overlap between the "highly security conscious" market and the market for DRM'ed games/movies (at least not on the same system), but we do get a regular stream of complaints from people trying to run non-DRM'ed games on a distro that was built without microcode images. I'm sure NVidia gets the same complaints.

              Then again, those users tend to end up installing proprietary drivers since that tends to be easier than installing microcode / rebuilding the initrd (one of the reasons I think current guidelines are broken) so you may not be counting them as part of the "real" Libre OS market.
              Last edited by bridgman; 05 May 2015, 03:38 PM.
              Test signature

              Comment


              • Originally posted by bridgman View Post
                That's the part I'm less sure about. I do agree that there's probably not a big overlap between the "highly security conscious" market and the market for DRM'ed games/movies (at least not on the same system), but we do get a regular stream of complaints from people trying to run non-DRM'ed games on a distro that was built without microcode images. I'm sure NVidia gets the same complaints.

                Then again, those users tend to end up installing proprietary drivers since that tends to be easier than installing microcode / rebuilding the initrd (one of the reasons I think current guidelines are broken) so you may not be counting them as part of the "real" Libre OS market.
                Huh, that's odd. Iirc on Debian it was a matter of apt-get installing one package and Fedora comes with microcode available out of the box. Do other distros make it overly complex then?

                Comment


                • No way a closed driver is part of a Libre OS

                  Originally posted by bridgman View Post
                  That's the part I'm less sure about. I do agree that there's probably not a big overlap between the "highly security conscious" market and the market for DRM'ed games/movies (at least not on the same system), but we do get a regular stream of complaints from people trying to run non-DRM'ed games on a distro that was built without microcode images. I'm sure NVidia gets the same complaints.

                  Then again, those users tend to end up installing proprietary drivers since that tends to be easier than installing microcode / rebuilding the initrd (one of the reasons I think current guidelines are broken) so you may not be counting them as part of the "real" Libre OS market.
                  I do not count an install using a closed driver as one that would be expected to even light the display without the microcode that goes with that driver. If an open driver came with open microcode I would not expect that to work either when only half-installed. Also, some people might have a closed install on one machine or drive, and an open one on another. I would consider the Windows install unsafe on the same machine due to the probable hardware logging by MS. Also, closed-OS entertainment systems (notably MS Xbox) have been exploited by spy agencies to use their video cameras (as in the Kinect) to watch a room. Thus, a hypothetical encrypted Trisquel machine with an Xbox able to see the keyboard from directly above would be considered at risk of keylogging by the camera. I tested camera keylogging from the sides or back, found it ineffective against a dummy passphrase.

                  Back in 2012 when I played with both AMD's and Nvidia's closed blobs, I made a point of not entering any encryption passphrase while X was running, nor the master one if X had been run. With UMS switching, the video card was still in framebuffer mode when the passphrase was entered, and the blob not yet loaded. A serious nuisance but one I deemed necessary. Decent open drivers for AMD solved that problem. The machines in question did not handle Snowden level material, only Occupy Wall St/Occupy DC level secured material. I must have done something right judging by the machine stolen in a 2008 raid that defeated police forensics.

                  The closed microcode (and unknown HW gates) I really worry about are not on the GPU at all, they are on the CPU. Both Intel and AMD use it, normally with a default blob in flash and the ability to run disk loaded code replacing it. The latter Intel learned the hard way from the Pentium floating point bug. There are three kinds of attack I worry about: efforts to log in one place all IP addresses a particular machine connects from, keyloggers in general, and dedicated keylogging attacks on both online and offline (disk encyption) passphrases. Since passphrases are normally not echoed to the screen, it makes sense that any keylogger triggered by say,. a special incoming packet, would be in the CPU firmware. This is why the Guardian journalists handling the Snowden take used a machine that had never been on any network to decrypt the take. That way any such triggerable malicious HW/firmware could not be turned on. It was presumed that always-on remote attacks would show up in Wireshark ansd thus could not be considered.

                  An elementary precaution is this: fire up wireshark and connect to a network with no browser, package updater, or other known online activity taking place. See what IP addresses show up, and if any do, open them in a browser. This will catch all the "phone home" software you may have missed. A direct check on AMD firmware for a GPU could be done by comparing this with and without the firmware loaded, but there is no way to repeat this check with no CPU firmware at all loaded as the CPU presumably does not have enough "bare metal" function to allow getting to the DE, connecting to a network, and running Wireshark.

                  One final point: Open microcode source that builds on a closed compiler to a GPU or CPU with an unknown command set would be one more piece of the puzzle, but still require a lot of RE to understand or to audit the whole setup. Possibly the compiler could be deduced from the source and the binary, rather like a known plaintext attack on encryption, but as with encryption this would not always work. A verifiable system requires a fully open stack that someone actually watches from the application all the way down to the physical hardware gates. App, OS, microcode, all compilers, and all hardware gates have to be known for "turtles all the way down" trust. Unless the FSF can get that out of the manufacturers there won't be a reason to blacklist one more piece of firmware for most moderate security cases, but also no ability to trust any electronic device at the highest levels.

                  Hell, Putin uses a typewriter and probably a manual one as his former agency the KGB had developed a device to keylog the IBM Selectric by monitoring the voltage drops on the line resulting from each character's different load on the motor.

                  OK, back to a way to get an open GPU: One layer, the firmware, can be taken out of the picture if a tiny card chosen only for power consumption is run with the firmware not installed. This card can only take the image you give it and put it on the screen. How about a coprocessor optimized to run the existing LLVMpipe driver on an FPGA, using the PCI-e bus to move the final video data to the card which is then just treated as an output device? My Bulldozer proc (an 8-core or well hyperthreaded 4) can run LLVMpipe/modesetting well enough for the desktop, if it were ten times faster it could do most of the Linux games I have. How big would an FPGA have to be to be ten times faster than this CPU for the single job of running a highly parallelized video driver? All the code and all the gates would be known.

                  Comment


                  • @bridgman

                    Dejavu with that "open microcode for old cards" perhaps?

                    @Luke

                    Not enough money, all open gpu projects failed.

                    Comment


                    • Yeah, there is something familiar about all these discussions

                      I thought Luke had an interesting point though. The "open for the sake of being open" market hasn't really materialized, primarily because most of the target market wants to be able to game etc... which means a fairly significant chunk of hardware is required.

                      What Luke is suggesting, however, is a bit different - defining an "open for the sake of being 100% auditable" market where the target user is probably *not* looking to run games on the system, and where a lower level of performance would probably be sufficient.
                      Test signature

                      Comment

                      Working...
                      X