Slashdot Mirror
NVIDIA Begins Requiring Signed GPU Firmware Images
An anonymous reader writes: In a blow to those working on open-source drivers, soft-mods for enhancing graphics cards, and the Chinese knock-offs of graphics cards, NVIDIA has begun signing and validating GPU firmware images. With the latest-generation Maxwell GPUs, not all engine functionality is being exposed unless the hardware detects the firmware image was signed by NVIDIA. This is a setback to the open-source Nouveau Linux graphics driver but they're working towards a solution where NVIDIA can provide signed, closed-source firmware images to the driver project for redistribution. Initially the lack of a signed firmware image will prevent some thermal-related bits from being programmed but with future hardware the list of requirements is expected to rise.
I'm guessing this is a response to Alibaba, where you can buy a $300 graphics card for $100 so long as you're OK with being an $80 card with a flashed bios. Remember folks, if it looks too good to be true it probably is :(.
Hi! I make Firefox Plug-ins. Check 'em out @ https://addons.mozilla.org/en-US/firefox/addon/youtube-mp3-podcaster/
"NVIDIA, f**k you!" - Linus Torvalds
That's the god damn fucking last straw. All these years I thought Nividia was slowly being dragged into the open by Nouveau. Digging their heals in but still an inexorable movement in the direction of the inevitable. But jesus fucking christ this move is such bullshit, 2 steps forward and 5 steps back. No more nvidia for me. They've just made AMD the only choice for graphics cards.
Yeah. F**k Nvidia for keeping scammers from selling faulty video cards with hacked bios's.
How dare they protect their brand integrity!
Surely it is impossible to have an opensource software if it needs a key to build it into a runnable program?
I mean you have the binary but you cannot recreate it from the source without that key to sign it with. The key is part of the source and you don't have it.
If the firmware were on a flash memory soldered to the video card's PCB, there wouldn't be a problem. But a lot of devices that use a proprietary blob omit the flash to save a few cents and expect the driver to copy this blob to the device at each boot. So in this case, firmware is part of drivers.
Yes, you are wrong. Back in 2007 AMD started releasing developer documentation and support for the development of open source drivers. This is the "Radeon" driver that you may see in repositories, and it's pretty good at this point. I don't know if 3D is fully supported, but for desktop stuff it's stable. That's in contrast to the Nouveau open source driver for Nvidia cards, which is reverse engineered.
What you may be thinking of are the closed source drivers for Linux: Nvidia's closed Linux driver is better than AMD's. AMD's used to be notoriously bad, but it's gotten better over time. To my knowledge it's still not as good as Nvidia's, but they're both usable at this point.
And Linux gamers will use the proprietary driver anyway because the vast majority of games with professional-class production values are proprietary software, so it's not introducing any extra taint.
You are right, they are not the same thing. However, some pieces of hardware have no firmware instanlled and require the driver to upload it on boot. I have no idea if that's how nvidia cards work, but I know that years ago when I was using hauppauge analog tv capture cards, this was exactly the case. Instead of flashing the firmware to the card, it just gets loaded every time you reboot. In these cases, people passionate about open source are probably going to want to use open source firmware to go with their open source driver. Or perhaps using the closed source firmware with the open source driver isn't even an option. I really don't know.
The only people who are going to get butt-hurt over this are a tiny fraction of Linux users who represent a tiny fraction of a tiny fraction of the GPU market.
I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
Surely it is impossible to have an opensource software if it needs a key to build it into a runnable program?
Of course you can under TiVo's interpretation of GPLv2, so long as the key is not an executable part of the program. The publisher can apply the signature key as part of linking the executable.
I mean you have the binary but you cannot recreate it from the source without that key to sign it with.
You're referring "Installation Information" in GPLv3. GPLv2 refers to something similar in "scripts to control compilation and installation", but it's not nearly as explicit as in GPLv3.
Then don't buy Broadcom. Requiring that a signed non-free blob be copied to the device on every boot is fairly strong evidence that NVIDIA and Broadcom have no plans to ever qualify a product for Free Software Foundation's "Respects Your Freedom" certification mark.
I've had it. I don't understand why they don't just release all of the specs of the cards. Why don't they give them away for free? Or provide a 3D-printable download at the very least. Fuck nVidia!
On the other hand, nothing tastes quite as good as the tears of an engineering group that put several million dollars into R&D for a DRM scheme, just to have it broken by a Swedish teenager three days after their product goes live.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
Or just want the drivers to work, which might require some patching. okay, the nvidia driver works ootb in most cases, but in the past there were vmware-driver patches for each new kernel.
If it's flashable, it is hackable, right?
Perhaps the part that verifies the signature isn't flashable. Consider the Wii video game console's boot process. When the Wii is turned on, the first stage bootloader in mask ROM on the I/O processor ("boot0") loads the second stage ("boot1") from NAND flash and verifies its hash against a hardcoded hash stored in one-time-programmable (OTP) memory on the I/O processor. System updates cannot change boot1. Then boot1 loads the third stage ("boot2") from NAND flash and checks its RSA signature by comparing the hash of boot2 to the expected hash decrypted using Nintendo's public key. Try to change boot1, and its hash will no longer match the value in OTP. Try to change boot2, and its hash will no longer match the signature. (That is, unless you have an early Wii whose hash comparison function was b0rked.)
the companies have licenses, which prohibit distribution of the fireware, except for some ways they thought of (like download of the official windows driver). So distributing the fireware itself is illegal and you get tools like the bcm-firmware-cutter, which extracts the firmware from the windows driver binaries. This is legal, as long as the user downloads the firmware (so the tool maintainer does not distribute anything from the company).
With all this hassle nowadays - I remember the times when nVidia was the only company supporting Linux and was something like the darly child of the FOSS community - which company actually *is* the most FOSS friendly today? Intel? AMD/ATI? Some other company?
Educated opinions on this needed.
We suffer more in our imagination than in reality. - Seneca
they are capable for a little while. Usually the 90 days to get out of any warranty work. Maybe a few of 'em even run at the clock freqs without crashing. It's not just clock freq either. Nvidia shuts off broken cores in software. You're games might run but they'll crash a lot. What Nvidia's worried about is that You'll blame them for a buggy card and go buy AMD. It has major brand damage potential especially with Alibaba about to become a household word what with their IPO.
Hi! I make Firefox Plug-ins. Check 'em out @ https://addons.mozilla.org/en-US/firefox/addon/youtube-mp3-podcaster/
So, they're locking out things that can brick the card (flash ROM/fuses, screw up thermal sensors) and apparently a hint of OS security (the Falcons that respond to userspace commands can no longer access physical memory, only virtual memory). The latter sounds somewhat bizarre, considering the firmware should be fully under the control of the driver, not userspace (I guess/hope?), but not unreasonable. Maybe there are software security reasons for this.
Nouveau is free to continue using its own free blobs or to switch to nvidia's. If they start adding restrictions that actively cripple useful features or are DRM nonsense, then I would start complaining, but so far it sounds like an attempt at protecting the hardware while maintaining manufacturing flexibility for nvidia. This isn't much different from devices which are fused at the factory with thermal parameters and with some units disabled; the only difference is that here firmware is involved.
NV seem to be turning friendlier towards nouveau, so I'd give them the benefit of the doubt. If they wanted to be evil, they would've just required signed firmware for the card to function at all. The fact that they're bothering to have non-secure modes and are only locking out very specific features suggests they're actively trying to play nicely with open source software.
Probably whatever GPU is in a Respects Your Freedom certified laptop such as the Gluglug X60.
Which is fine, most people will just use the binary driver. At the end of the day I care about stability and performance.
I thought the SHIELD was also a standalone Android device. You can probably just use any remote desktop app that supports OpenGL.
Most of people running gaming GPUs on linux are probably gaming.
That means nvidia's own closed source drivers. Open source drivers are utterly crippled when it comes to gaming, and it would take a huge masochist to use them.
Shield is an ARM tablet that's shaped like a controller. Being able to stream a game from your GPU is just one of its functionalities.
Andy Ritger at Nvidia is already in talks with Ben Skeggs and Martin Peres with Nouveau. They're are going to hash out the details at XDC2014. The impact for Nouveau is in the packaging and distribution parts of the cycle, not development. Also, it was Nvidia who reached out to Nouveau, not the other way around. Nvidia has their reasons for doing this, but it's not an anti FOSS thing. It's more likely one of the more sane reasons posted above.
So everyone just relax their sphincters a bit....
Yeah, but first sale doctrine says that when you buy something: ITS YOURS! You can do whatever you want with it. Use the brand new car you bought as a boat or airplane? Sure, whatever floats your boat. But a lot of technology companies want to screw you over and say "no, we don't want you doing that with our stuff". A lot of them will make a standard product, then sell it as tiered products by crippling functionality. Enough. AMD has good functionality out of the box with open drivers. The kernel get along with it. No crippled functionality. I had had enough of NVIDIA from my last computer, and when I built this one, I went with an AMD card: and it was borked, and the store had a replacement NVIDIA card. OK, back to NVIDIA (by the narrowest of margins). Next box (and its getting soon now): AMD!
It depends.
If the blob is only needed to control the thermal logic on the chips, then the vast majority of the open code that's required (interfacing with the buses, talking to the chips, converting and uploading primitives and textures to RAM etc.) is still under the control of the OS.
I see it as akin to the wireless devices where the region-specific allowed frequencies are used. The operation of the chip - it's loading order, it's interaction and security of RAM, it's performance, it being under the control of the OS, etc. is all there. But the one bit that nVidia can't take a chance on - the dangerous stuff that you shouldn't be playing with anyway if you're concerned about the integrity of the device - is in firmware. Would it be worse if that just existed on a ROM chip and you couldn't change it at all? Probably. At least this can be upgraded to new versions.
And the requirement for open-source is that the card can play nicely with other code - that it interacts with the OS and other drivers nicely without having to rewrite PCI drivers or hand over full control of DMA of any part of RAM to the device. That's the point of Noveau, that's WHY we want to avoid blobs. And this looks like a blob that doesn't actually matter. It could be on the card, and we wouldn't care. But if the PCI interaction logic or the DMA code that the OS has to execute is just on card ROM, then it's a whole lot harder to make the damn thing work for Linux, etc. instead of just the main market of Windows.
Similarly, the wifi debacle of a few years ago - no, we don't want to just be passing off random blobs whose "open" parts are to basically hand off complete DMA / USB access to the device and the blackbox of code makes it work. But if we have to have a firmware of just the essential, must not play with, vendor-supplied part that doesn't interfere with operation and we can revert it at any time - that's a tiny, tiny loss for a massive, massive gain: vendor support without fear of litigation if they somehow "approve" our code that might transmit on frequencies it's not allowed to, or fry our cards.
It's not perfect, but it's a damn sight better than some other companies offer at all. And there seems to be good reasoning behind it. And, in the end, it won't affect your use of the card for any of the primary goals you buy it for, nor will it break when you go to a Linux 3.6 kernel because they never updated the PCI code in the wrapper, or whatever.
Intel has I believe all their Linux drivers fully open sourced. However, they're not really fast compared to AMD or NVidia. AMD has two driver versions, their closed source catalyst driver and the open source one. The catalyst driver is much faster, energy efficient and can do more tricks than the open source one. NVidia is sort-of supporting Nouveau and has their own binary driver as well. The "sort of supporting" is much limited compared to the amount of AMD is pouring in the open source version of their drivers, but it has improved greatly recently.
Depending on what you are looking for in terms of bang for buck, speed or features each of these might be "the best solution" for your needs. If you want CUDA or openCL, you'll be looking at closed source though, there's no serious support for open source drivers for relevant hardware (yet).
I was promised a flying car. Where is my flying car?
I was always torn on buying NVIDIA or not.
Well, this is hardly a reason to buy AMD hardware instead. They already ship the firmware blobs with radeon driver.
Keep dreaming. Linux on the desktop yet? :)
At the rate Microsoft is going in their mad race to piss off & alienate just about everyone with a high-end workstation (by pushing Windows towards dumbed-down touch-based interfaces), that goal is actually starting to look attainable. Five years from now, one of two things will likely happen:
* Microsoft will have finally pissed off & alienated enough users for some critical mass of high end desktop/workstation power users to decide Windows is annoying them more than making their lives easier, and vendors like Adobe will notice & release their flagship software for Linux (effectively destroying what little market would remain for high-end Windows applications).
* Hedging their bets, companies like Adobe will port their flagship apps to Linux... then port them back to Windows with "kde6.dll" as a dependency. IMHO, this is Microsoft's ultimate nightmare scenario. If the apps high-end workstation users care about are all native KDE apps with equally good Linux versions, there's literally nothing left at that point to keep them chained to Windows. They'd basically be running Linux under a Windows kernel through a compatibility thunking layer anyway. ESPECIALLY if the apps are licensed in a way that allows users to buy the app once, then install & run it under BOTH Windows AND Linux.
Why KDE, and not Gnome? Licensing & logistics. KDE is Apache-licensed, so there's nothing to stop Adobe from bundling an installer for KDEwin directly into their own installers to auto-install it if the user hasn't done so already. And KDE for Windows already exists in beta form (see: http://windows.kde.org/ ).
Five years from now, we might not all be running Linux per se... but most of us will probably be running "Winux" (Windows kernel, Linux UI).
Once upon a time, there was this stuff called "Read Only Memory". Not EPROM or EEPROM, but ROM. Once it was created you couldn't change the contents of it.
If I was worried that scammers were going to take a board that I was selling as a Whizzo rather than a Whizzo Plus because it didn't meet Whizzo Plus specs, and flash it as a Whizzo Plus anyway to rip off customers, I'd put "Hi there I'm Whizzo serial number 987654321 born 2014-09-24-18:58:56 GMT at the Utopia Planitia assembly line, signed <digital signature>" somewhere in a bit of that old-fashioned Read Only Memory soldered to the board in a tamper-resistant manner, and also have that serial number etched into the board.
Tom Swiss | the infamous tms | my blog
You cannot wash away blood with blood
Working with a complex scene in Blender with a Intel "graphics" is about as fun as rubbing sandpaper in your eye.
For large sets, this will be our guide even unto death, for the LORD will work for each type of data it is applied to...
If Nvidia is really only doing this to stop 'counterfeit' chinese cards, they should provide a public covenant that they will release signing keys necessary for consumers to reflash their own hardware once the market for counterfeit cards has sufficiently dwindled (say two card generations, or two years, whichever is longer.) This has all the benefits of eliminating counterfeits where it counts, while also ensuring to the consumer that they will have full control over their hardware once enough time has passed to eliminate the profitability for counterfeiters and the related support issues for Nvidia.
Thoughts and/or email campaigns to get this into place?
I imagine working on it with open source nvidia drivers is not going to be much better, just in a different way. One is painfully slow, other is less slow but painfully crashy.
Yep, unless you've got one of a quite small list of well-supported cards. Those are not so powerful these days, but if you've got one then you're still worlds better off than with an Intel.
I've tried... two ATI (back then) cards, one I never got to work, and the other found all sorts of interesting ways to crash and malfunction. Have to admit I haven't tried again since - the devil you know and all that.
For large sets, this will be our guide even unto death, for the LORD will work for each type of data it is applied to...
"The FOSS community" is tiny. The vast majority of the time Linux is selected for practical or pragmatice reasons. Most people using Linux aren't using it for ideological reasons. There aren't enough people prepared to boycott NVIDIA over this to make a difference. Also, it's firmware that needs to be signed, not drivers.
After all its artificially limiting what you can do with the hardware. Plus it'll mean you'll have to run closed source firmware from the manufacturer on the device, which means that it'll probably contain malware. Why else would you distribute software in object code only? (No, competitors probably have reverse engineered it years ago.)
Why not just use closed source drivers?
About the only reason I can see not to is putting ideology ahead of pragmatic solution in a problem where being pragmatic will have little to no impact on ideological struggle for open source. Nvidia won't care either way and won't open source its drivers even if every single linux user were to ask for it. Too small of an audience.
The 3d stuff does work, just not for the latest cards.
Are you sure? You may need a more up-to-date kernel than your favorite distro provides to support the latest cards, but I certainly had the impression that AMD is actively pushing code into the mainstream kernel. Southern Island and Sea Island chipsets are both supported in 3.16 (and possibly earlier).
3D performance on many ATI/AMD cards is actually better with the open source kernel drivers than with the proprietary drivers if you have a recent enough kernel, according to some reports I've heard.
That's the question I ask myself, and I don't have a satisfactory answer. I use the proprietary drivers.
For large sets, this will be our guide even unto death, for the LORD will work for each type of data it is applied to...
For older cards, the OSS driver might end up being better than crapalyst.
Actually, it's the newer cards that are reported to have better performance with the latest OSS drivers.
This is a pretty recent development, though. A little over a year ago, everything I'd heard was in line with what you're saying. But when I heard about all the improvements in the recent OSS drivers, I took a chance and bought a box with ATI, just a couple of months ago, and I must say that it's been absolutely smooth, effortless, and 100% hassle free. With a 3.12 kernel (now upgraded to 3.14). And no catalyst.
If your experience is older than that, then I think your information may be out of date.
Not that I'm saying you should switch or anything. No skin off my nose. Just saying your data may be out of date.
Not so funny anymore.
http://www.dpreview.com/articl...