The Linux 6.6 modules infrastructure is changing to better protect against the illicit behavior of NVIDIA’s proprietary kernel driver.
Luis Chamberlain sent out the modules changes today for the Linux 6.6 merge window. Most notable with the modules update is a change that better builds up the defenses against NVIDIA’s proprietary kernel driver from using GPL-only symbols. Or in other words, bits that only true open-source drivers should be utilizing and not proprietary kernel drivers like NVIDIA’s default Linux driver in respecting the original kernel code author’s intent.
Here’s a wild idea, NVIDIA: just release your driver code as open source.
Not a snowball’s chance in hell. Nvidia’s value proposition is software as much as it is hardware. First of all, Nvidia has a reputation of being the best implementers of the “high level APIs” (such as OpenGL, Direct3D 11, Direct3D 9), which is something really not trivial to achieve, and then there is stuff like PhysX and CUDA which is deeply proprietary.
Yes, I know, AMD GPUs are excellent at Vulkan and OpenCL. Thing is, gamers also want to run games using the old “high level” Direct3D APis (and PhysX is a nice bonus too), then there are businesses that need a good OpenGL implementation, and then there are businesses that buy tons of datacenter GPUs that are locked in to CUDA. Nvidia has been working on their “drivers as a competitive advantage” strategy for too long to just open-source their drivers. When push comes to shove, they have shown they’d rather drop support for a platform (for example MacOS) than open their driver. Same will happen with Desktop Linux.
kurkosdr,
True, and it is more than that.
When we download “Game Optimized Drivers for Diablo”, it is not actually optimizing the driver, but more like fixing bugs in the game engine itself. They would analyze and debug recent releases, adopting their drivers on the fly, usually based on the binary names.
(Yes, this had led to cheating when they recognized common benchmark binaries as well. Not only nvidia, but others were guilty in this).
Same is true for machine learning and AI stuff. Being able to optimize “kernel” graphs gives a significant competitive advantage.
So, while it would be really nice if they open sourced the drivers, as you suggested, I don’t expect that to happen anytime soon.
Playing devil’s advocate here, but it’s irrelevant what linux devs want, only what the license says. And the GPL doesn’t prohibit creating new APIs to expose kernel functionality in new ways. The linux GPL flag was a creative way to mark modules in violation, but nothing legally prohibit FOSS developers from creating open source modules that expose new APIs, which is what nvidia did with their “open source linux drivers” that were reported on some time back…
https://www.howtogeek.com/805004/nvidia-releases-open-source-linux-gpu-drivers-with-a-catch/
Much to the annoyance of FOSS users, these open source modules are API shims and not full drivers. And regardless of the feelings the linux community has about nvidia, shims are not prohibited by the GPL. Without changing the license (which linux is unable to do anyway), this cat and mouse game between linux and nvidia can continue for the foreseeable future.
In theory Nvidia might play nice and back down on proprietary drivers of their own accord, but I honestly have a hard time envisioning that.
BTW what I thing will actually happen is that Nvidia will officially drop support for vanilla Linux kernel 6.6 and higher (like they dropped support for Linux kernel 5.9 and higher for a while) and will release a forked kernel that doesn’t include the new restriction. I mean, businesses locked in to CUDA and running Linux datacenters will use the forked kernel, much like some ARM SoCs require forked Linux kernels to work and device manufacturers have to use those forked kernels either the want it or not to make the SoC work.
Gamers using Nvidia cards to run games? Yeah, Nvidia doesn’t care.
(I mean gamers using Nvidia cards to run games on Desktop Linux obv)
Most likely someone will release patches that reverts these changes. I suspect it’s a very easy change.
jgfenix,
It’s not really a technical obstacle. Nvidia can easily create modules that do what they need. The battle is really over the way nvidia is sidestepping kernel flags TAINT_PROPRIETARY_MODULE and EXPORT_SYMBOL_GPL, to calculate whether linux considers the kernel GPL compliant.
The problem here is that nvidia are technically able to create a GPL compliant module that exposes functionality needed by their proprietary drivers and there’s not much linux devs can technically do to stop it. There’s going to be a lot of fighting, but unless nvidia are willing to open source their code, I don’t see it getting resolved, just more cat and mouse games like this.
I think the kernel devs don’t want to prevent Nvidia from having proprietary drivers (or modules serving proprietary drivers), but preventing the proprietary drivers from doing some things it shouldn’t be doing (either itself or via a module acting as a proxy).
kurkosdr,
I think we’re getting into semantics here, which is dangerous territory, haha. The issue for kernel devs is that nvidia drivers are doing things that they feel shouldn’t be allowed from non-GPL code. From the article…
So while I agree with parts of your quote, the “shouldn’t be doing” part centers around the fact that nvidia’s drivers are proprietary and not GPL. Having a proxy that complies with GPL but provides a new API to sidestep restrictions put in place by kernel developers undoes the restrictions kernel devs intended for non-GPL code.
Ironically though I don’t think linux kernel developers can legally enforce any restrictions above and beyond what’s already in the GPL 2 license itself because the GPL 2 license explicitly forbids it:
https://www.gnu.org/licenses/old-licenses/gpl-2.0.html#SEC1
For this reason I think it’s completely irrelevant what the kernel developers say or think, they have to abide by the license just like everybody else. They are not allowed to add more terms.
If nvidia manages to technically bypass the need to import GPL code through use of a proxy, then it allows nvidia to defeat the GPL requirements of the kernel since only the proxy itself needs to be GPL.
To clarify, I am not a fan of what nvidia are doing with proprietary drivers on linux. It’s actually very bad for users to be dependent on proprietary bits. But in terms of this quarrel between nvidia and kernel devs, I think it will be very difficult for kernel devs to change nvidia’s stance on proprietary drivers.
The kernel devs are arguing that Nvidia’s behaviour is illicit on “DMCA circumvention of access controls” grounds, not copyright grounds:
https://www.phoronix.com/news/Linux-6.6-Illicit-NVIDIA-Change
But this argument is never going to be tested, so it’s irrelevant anyway.
This time it looks like they closed the loophole for good, since any GPL module that serves a proprietary driver is locked out of the GPL-only functions, so I don’t expect a cat-and-mouse game. Nvidia will likely tell Desktop Linux users to not use kernel versions 6.6 and higher (they don’t care about Desktop Linux users anyway) and for their datacenter customers, they will ship a forked kernel without the lockout. I mean, they already ship a datacenter-grade ARM board in the form of the DGX GH200, so delivering their own forked kernel is not a stretch.
kurkosdr,
I’m really confused by your statement because DMCA *is* copyright. I did read the article but it still seems like that linux dev want to enforce new technical restrictions (ie “defenses”) on linux usage beyond those spelled out in the GPL 2 license.
As far as DCMA anti-circumvention clauses go, without evidence that copyrights are being infringed in the first place, I don’t feel that has much merit. Obviously the anti-circumention clause exists to stop usage that is inconsistent with the license, not usage that is consistent with it.
I couldn’t edit my post.
Obviously code running in ring 0 can do whatever it wants and this changes nothing. The main question for me is whether mainstream distros will support or reject the nvidia drivers.