Announcement

Collapse
No announcement yet.

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

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

  • ossuser
    replied
    Originally posted by bridgman View Post
    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.
    The gaming market is a big market.

    But I also think most users don't run games, as they only have a computer to do some webbrowsing, mail etc.

    The market you mention here would thus be your main users, isn't it ?

    Leave a comment:


  • bridgman
    replied
    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.

    Leave a comment:


  • curaga
    replied
    @bridgman

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

    @Luke

    Not enough money, all open gpu projects failed.

    Leave a comment:


  • Luke
    replied
    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.

    Leave a comment:


  • nanonyme
    replied
    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?

    Leave a comment:


  • bridgman
    replied
    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.

    Leave a comment:


  • Luke
    replied
    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.

    Leave a comment:


  • bridgman
    replied
    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.

    Leave a comment:


  • bridgman
    replied
    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.

    Leave a comment:


  • Luke
    replied
    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...

    Leave a comment:

Working...
X