Linux 6.6 To Better Protect Against The Illicit Behavior Of NVIDIA's Proprietary Driver

[timofonic]

Obviously the added defense lines are crap and very slowly updated. They should be more aggressive, this seems a farce to pretend to disincentive proprietary drivers.

Nvidia has the GSP binary blob to hide their crap on it and that open source driver, merge it upstream and kill the proprietary one eventually.

BSD and ZFS lovers: This isn't against non-GPL open source modules, but about proprietary drivers. Nvidia is a real PITA for kernel development, too many bugs on too many machines and impossible to debug. Also, Nvidia proprietary drivers are extremely obfuscated that even an interactive disassembler tool such as IDA Pro or Ghidra make it practically impossible to reverse engineer it.

[avis]

Nvidia has the GSP binary blob to hide their crap on it and that open source driver, merge it upstream and kill the proprietary one eventually.

AMD and Intel have smaller blobs as well. So what? And without those blobs they don't generally work. My AMD RDNA 3.0 GPU doesn't even start when there's no firmware. An instant kernel panic on boot.

Nvidia is a real PITA for kernel development, too many bugs on too many machines and impossible to debug.

1. NVIDIA drivers have never affected kernel development in any shape or form. The first part of this sentence is simply a lie.
2. What bugs are you talking about? How does this affect the kernel and people who don't use NVIDIA GPUs? Citations needed.
3. Impossible to debug what exactly? Again how does this affect the kernel and people who don't use NVIDIA GPUs? And again citations needed.

When was the last time you opened LKML or bugzilla.kernel.org? I've done so several times just today. In fact I'm an admin on bugzilla.kernel.org and I've not noticed anything that you've been talking about.

I understand your life is ruined that NVIDIA exists but at least get your facts right.

Also, Nvidia proprietary drivers are extremely obfuscated that even an interactive disassembler tool such as IDA Pro or Ghidra make it practically impossible to reverse engineer it.

How is this relevant at all? It's proprietary, period. You don't like proprietary, you buy AMD/Intel GPUs.

Throwing random facts in just for good measure doesn't work - it shows how weak your arguments are. I mean your attacks. No actual arguments have been provided in your message. None.

[jacob]

this also affects eg zfs.
i thought linux is about choice.

No one who's actually involved in the development ever said anything about "choice". Linux is about the GPL licence. No-one is prevented from supporting Linux or using it, but they must do it on Linux's licence terms, just like with every other OS. I really don't see the logic behind the idea that Linux should compromise its own legal status to make life easier for Nvidia. It's not like there are no competing GPUs available either. So Nvidia can be honest, transparent and lawful, or it can GTFO.

[Barley9432]

no, this is copyright infringement by NVIDIA (proprietary driver).

See:

https://www.gnu.org/licenses/gpl-violation.en.html

As such it needs to be stopped -- or copyright infringement is only valid for closed-source software?

This is stopped in the courtroom not with this pettiness. If they are truly in violation of the GPL then they can be taken to court. If they aren't (which is clearly the case here), then this is just someone holding a grudge.

[skeevy420]

....as far as OpenZFS goes, it's open source and anyone who can compile a kernel can patch it to include OpenZFS natively to get around all this module nonsense. Just don't distribute that kernel because that's illegal.

That's also one of the steps in making a WSL2 kernel that can access ZFS volumes on Windows

[piotrj3]

no, this is copyright infringement by NVIDIA (proprietary driver).

See:

https://www.gnu.org/licenses/gpl-violation.en.html

As such it needs to be stopped -- or copyright infringement is only valid for closed-source software?

This is very complicated issue, there are cases GPL can be combined with closed source software.

Not a lawyer.

1st. communicaton has to be done on arms lenght - and Nvidia does it by having in between kernel an open source library that communicates with kernel.

2nd. Nvidia driver is seperate program (that is not a question) and isn't distributed in most cases with kernel. Closed source part is also shared between many diffrent systems so you cannot argue it is part of linux as it can function without linux (on freebsd/solaris/windows etc..).

If you made closed source product that integrated tightly with linux (so no arms lenght) and thing only worked on linux and was heavy dependant on linux-only features to achieve its functionality and distributed it with kernel as one product it would be GPL violation.

Thing is even if Nvidia didn't do open source library in between even if they violated GPL on all possible symbols in kernel. They wouldn't violate GPL because they don't distribute GPL code themselves. The person that binds GPL code (linux ) with non GPL code (nvidia driver) is user. You could make a claim that user breaks GPL but he doesn't because he doesn't distribute his system. If user had linux + nvidia and after distributed his system with both of them glued together that could be potential GPL violation, because he distributed GPL code with non GPL closed source compiled by him (not nvidia) against each other.

You could make a also soft claim that Ubuntu installer (or other installers) that allow you installing linux kernel with nvidia driver do potentially violate GPL. But it is much softer case as decision yes/no is done by user so user compiles stuff against each other.

skeevy420 's answear above regarding ZFS also applies to Nvidia. GPL doesn't care if your code is open source or closed source, - what it has to be is GPL compatible. ZFS not being GPL compatible cannot be distributed together with kernel. Nvidia not being GPL compatible cannot be distributed as well together with kernel.

[mSparks]

The principle behind the "GPL use only" symbols seems sound.

Basically, they mark kernel exports so badly written/undocumented you had to derive the work from gpl code to be using them.

worst offenders seem to be usb dongal manufacturers rather than nvidia, and they mostly seem to have just stopped supporting Linux because of this years ago.

I do suspect the author of this commit is probably mistaken about nvidia using them tho, might be some wayland garbage, in which case it will just kill wayland support, which no one will care about anyway.

[Paradigm Shifter]

Oh well, drama in a kernel I won't have to worry about until it lands in whatever *buntu LTS or Debian Stable release it comes in.

Very doubtful. They are very profitable and things are going just fine for them.

Yup.

I remain convinced that had nVidia's acquisition of ARM been permitted, that nVidia would have done an Apple and gone completely closed ecosystem. They bought Mellanox. They were hiring BSD developers in large numbers and had proof-of-concept ARM/nVidia offerings.

If they owned ARM as well, they would have had all the expertise necessary for a complete systems solution, removing any sort of dependence on x86, Windows and Linux and permitting everything from single workstation systems all the way up to server farms and supercomputers at whatever price they thought the market could bear. This would increase vendor lock-in, as well, which while it puts many voluble internet denizens off, an astonishingly large number of people simply don't care - offer discounts to universities/students (as many software companies do) and people would be graduating only knowing how to use nVidia systems (kind of like artists with Adobe, etc) so they (and their employers) would end up being increasingly resistant to any alternatives.

The biggest market for nVidia - HPC (now AI) - would have either stayed with them (because they were throwing tons of cash at them already, and that would likely be cheaper in the short/medium term than having to rewrite everything for AMD (and/or Intel) compute paths from CUDA) or likely a small section would have moved to AMD, as at the time Intel had no GPU accelerator offering and AMDs GPU compute support was... underwhelming.

Even now, in my field, CUDA is it. There was movement last year to attempt to make progress with AMD and Intel alternatives (because Ada Lovelace card prices were a bitter pill) but even with direct support from Intel and AMD, forward momentum appears to have died. The promise (whether real or imagined) of ROCm support on the consumer 7000 series sparked interest, but never materialised.

[RejectModernity]

It's sad to see the 100500th confrontation between the people who have never contributed to the kernel, yet they want to deprive others of using their existing GPU with Linux and instead force them to buy a new GPU. This screams of of being elitist and haughty but I just don't care any longer. Too tired of hatred, aggression, animosity and verbal attacks. This has really propelled Linux, oh, wait, it's only shown what kind of people represent Open Source.

Look mom, somebody on the internet called my favorite company worth $1.2B bad words. I will defend it at any cost!

[mSparks]

The promise (whether real or imagined) of ROCm support on the consumer 7000 series sparked interest, but never materialised.

While I agree with everything else. I think this is a little to soon to call.
AMD basically only have one card out at the moment that ROCm makes any sense for, the 7900XTX.
Its expensive, not sold in large numbers, and only been on sale for a few months.

When they can get similar silicon down to the few hundred $ mark, which is going to take a few years, CUDA for new dev is going to be a very hard sell.