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

[citral]

Good old "get out my linux" as a final argument .
Just admit the fact: AMD doesn't care about linux users. Nvidia does, they even hired people to somehow cope with petty dictators within kernel team.

Do you have anything more stupid to add?

[mSparks]

Do you have anything more stupid to add?

TBF, there's a pretty solid case that AMD didn't just "not care about Linux users", but rather they didn't care about desktop PC graphics generally for something like a decade.

I'm just not sure how else you can interpret AMDs hardware and software product launches for desktop graphics between January 2010 and December 2022. Even Apple and Intel decided they could do better for less. ARM and Apple did.

[creative]

The issue just isn't a Linux issue with certain games with AMD GPU's, the same graphics bugs in games present in Linux are mirrored in Windows.

I have a large installed steam and gog lutris library. You think if I get a new piece of hardware that I'm not going to put it through its paces with my favorite games? The 6800xt was supposed to be a superior GPU it got sent back, I found stuff on reddit posts and youtube trying to solve the stuff. People had the same issues with the same games except they were windows users.

[oiaohm]

Rest are MIT or NVIDIA licences.

You need to look at the MIT/Nvidia licensed ones not the GPL/MIT you will find Nvidia has been doing direct symbol look up in the Linux kernel. Yes this means you don't check if the function is "EXPORT_SYMBOL_GPL" flagged before using it.

[URL]The Kernel update retrospectively decided using these symbols was "GPL-violating" and broke the nvidia driver.

Not the case that it was retrospective at 5.9. 5.9 did not change any of the markings of "EXPORT_SYMBOL_GPL" so items that had been marked as internal/GPL code only just got enforcement against incorrect usage with 5.9.

5.9 adds the taint flag tracking that one method for attempting to use EXPORT_SYMBOL_GPL flagged functions would now fail inside closed source module.
https://lkml.iu.edu/hypermail/linux/kernel/2008.1/05371.html
That the change with 5.9.

The only way that goes off are using EXPORT_SYMBOL_GPL where you should not be. The symbols that did NVIDIA in with 5.9 were only tagged with EXPORT_SYMBOL_GPL 2014. Nvidia had 6 years to have their code base clean of them before 5.9.

OpenZFS developers did have a valid case with the linux kernel mode floating point changes.

[h143570]

At first, I thought this was about forcing NV to open source their drivers via a potential lawsuit / DMCA claim.

When a non-GLV2 module gets loaded even through intermediaries, it will cause the kernel to be tainted. Whenever a bug report is created with such a kernel, the mainline developers can safely redirect the bug report to the module developer in question as they are running a patched kernel, shifting the responsibility of investigating, fixing, and contributing back or maintaining the patches to the module and patch developer.

Contributing back to the fixes could be challenging for the module and patch developers as they would need to provide a reason without admitting to their guilt and being hit by DMCA.

Anybody using it would be left without mainline support and must depend solely on a single vendor. Many companies and organizations can't use it for legal and compliance reasons, even if they are willing to risk using it. The DMCA takedown would also loom over it.

[oiaohm]

Someone writes a MIT licenced module using sme_active() - GPL not violated
Someone else takes that module and incorporates it into a propriety module (neither GPL or MIT violated)

There is a german copyright case over it. What you wrote here is wrong because you have missed a basic license problem.

MIT is a GPL compatible license. The dangerous word is compatible because this is directional. Please note GPL is not a MIT compatible license this is one direct compatibility. If the Linux MIT module is declared a "Derivative Works" of the Linux kernel the license at play is not MIT but GPLv2 with the Linux kernel. German court gave this ruling in the past that MIT license can be overridden by a copyleft license. So the propriety module using MIT module could be required to obey all GPL license rules of course that means legally being on the hook for source code.

Yes GPL compatible licenses legally can transform into just being GPL license when mixed with a GPL work. Yes MIT has the same problem when mixed with CDDL. MPL and so on because it a compatible license with all these copyleft licenses. This is just a feature of copyleft licenses.

There was no new symbols tagged EXPORT_SYMBOL_GPL in 5.9 all the ones that tripped Nvidia up were tagged since 2014 with 5.9 so they had 6 years not to use them.

The ZFS one they had grounds. All the other links of examples you pulled in those had been tagged with EXPORT_SYMBOL_GPL before enforcement kicked in. Yes OpenZFS with floating point issue was caught out by old symbols getting EXPORT_SYMBOL_GPL added. Turns outs this is a rare event with the Linux kernel for a old symbol to have it EXPORT_SYMBOL value changed. Also newer versions of the kernel today those symbols are no more. New design for floating point in kernel space handling so the flag on floating point systems was because they were pulling those system internal because they were going to be eliminated and those functions were eliminated.

[mSparks]

You need to look at the MIT/Nvidia licensed ones not the GPL/MIT

How will that help find whether

by importing exports from their proprietary modules into an allegedly GPL licensed module and then re-exporting them.

Is fabricated BS or not.

Because the whole rant in the OP looks like fabricated BS, that the more you look into it seems like certain morons (who should lose their commit rights) harming everyone but Nvidia while trying to harm Nvidia for no other reason than their own over bloated ego.

[oiaohm]

Because the whole rant in the OP looks like fabricated BS, that the more you look into it seems like certain morons (who should lose their commit rights) harming everyone but Nvidia while trying to harm Nvidia for no other reason than their own over bloated ego.

by importing exports from their proprietary modules into an allegedly GPL licensed module and then re-exporting them.

Read the line careful. Nvidia exports functions out of there proprietary module then pulls the updated back in. symbol_get stuff is designed to be used in a protection way inside the Linux kernel to allow prevention of function infinity loops where a function basically calls it self for ever but this can be used the way Nvidia does to take imported function into another module and move it into your own.

The problem code is in the MIT/Nvidia licensed and what it doing to the GPL/MIT side of their driver.

Nvidia basically done stacks of stunts to get access to functions marked EXPORT_SYMBOL_GPL.

https://lwn.net/Articles/939842/

And just like here I don't believe it over. Why just block this exploit and Nvidia will do it again with a new exploit because they have in the past. Of course NVIDIA end users end up having different driver stability issues as Linux kernel developers change functions they believe they have absolute control over because they are tagged EXPORT_SYMBOL_GPL only to have Nvidia users start complaining. (yes this is how Linux kernel developers notice something is wrong over and over again)

5.9 was just a prior case of closing one of the loopholes.

Yes Nvidia argued that MIT wrapper like you did magically removed the GPL even that the court cases say no it does not and worse that the MIT code can just end up being GPL.

These protections basically prevent people from making the error that could end up in a court case that will waste the Linux kernel developers time. These changes should cause Nvidia drivers zero issues if they are not doing the wrong thing.

mSparks there is a particular reason why Nvidia wants access to the EXPORT_SYMBOL_GPL instead of using the EXPORT_SYMBOL versions. In general the EXPORT_SYMBOL_GPL versions are slightly faster because they don't have to maintain any form of legacy module compatibility.

Think about if all parties using a particular function are all meant to be mainline Linux kernel and all function usage should be in lock step with releases as everything tagged EXPORT_SYMBOL_GPL is intended to be you don't need to have any compatibility code wasting clock cycles. No compadiblity code means these are dangerous for third party Modules like Nvidia to use.

Yes build errors because you have used EXPORT_SYMBOL_GPL are useful. Yes OpenZFS cases was annoying but at least it was not like hey we have altered the function and opps users lost lots of data.

Items with EXPORT_SYMBOL_GPL like it or not Nvidia kernel module should not be using. Remember anything tagged EXPORT_SYMBOL_GPL can be deleted from the kernel without notice as well. Yes a symbol changing from EXPORT_SYMBOL to EXPORT_SYMBOL_GPL is notice this symbol could be going by by so you need to either change your code or get agreement in linux kernel mailing list for it to return to EXPORT_SYMBOL as a third part driver developer to the Linux kernel.

[piotrj3]

Read the line careful. Nvidia exports functions out of there proprietary module then pulls the updated back in. symbol_get stuff is designed to be used in a protection way inside the Linux kernel to allow prevention of function infinity loops where a function basically calls it self for ever but this can be used the way Nvidia does to take imported function into another module and move it into your own.

The problem code is in the MIT/Nvidia licensed and what it doing to the GPL/MIT side of their driver.

Nvidia basically done stacks of stunts to get access to functions marked EXPORT_SYMBOL_GPL.

https://lwn.net/Articles/939842/

And just like here I don't believe it over. Why just block this exploit and Nvidia will do it again with a new exploit because they have in the past. Of course NVIDIA end users end up having different driver stability issues as Linux kernel developers change functions they believe they have absolute control over because they are tagged EXPORT_SYMBOL_GPL only to have Nvidia users start complaining. (yes this is how Linux kernel developers notice something is wrong over and over again)

5.9 was just a prior case of closing one of the loopholes.

Yes Nvidia argued that MIT wrapper like you did magically removed the GPL even that the court cases say no it does not and worse that the MIT code can just end up being GPL.

These protections basically prevent people from making the error that could end up in a court case that will waste the Linux kernel developers time. These changes should cause Nvidia drivers zero issues if they are not doing the wrong thing.

mSparks there is a particular reason why Nvidia wants access to the EXPORT_SYMBOL_GPL instead of using the EXPORT_SYMBOL versions. In general the EXPORT_SYMBOL_GPL versions are slightly faster because they don't have to maintain any form of legacy module compatibility.

Think about if all parties using a particular function are all meant to be mainline Linux kernel and all function usage should be in lock step with releases as everything tagged EXPORT_SYMBOL_GPL is intended to be you don't need to have any compatibility code wasting clock cycles. No compadiblity code means these are dangerous for third party Modules like Nvidia to use.

Yes build errors because you have used EXPORT_SYMBOL_GPL are useful. Yes OpenZFS cases was annoying but at least it was not like hey we have altered the function and opps users lost lots of data.

Items with EXPORT_SYMBOL_GPL like it or not Nvidia kernel module should not be using. Remember anything tagged EXPORT_SYMBOL_GPL can be deleted from the kernel without notice as well. Yes a symbol changing from EXPORT_SYMBOL to EXPORT_SYMBOL_GPL is notice this symbol could be going by by so you need to either change your code or get agreement in linux kernel mailing list for it to return to EXPORT_SYMBOL as a third part driver developer to the Linux kernel.

https://lwn.net/Articles/215075/

The loading of proprietary modules was not banned for a few reasons, the first of which being that there is, in fact, nothing wrong with doing so. The GPL is quite clear in its statement that somebody who is in possession of GPL-licensed code can use it in any way they wish. If they want to combine their nice free kernel with a big, proprietary binary blob, they are fully within their rights to do so. So banning proprietary modules in the kernel source attacks the problem in the wrong place and attempts to forbid an activity which is allowed by the license.

Also read this https://lwn.net/Articles/214149/

This Linus Torvalds response should be literally framed and put on walls in room of every Linux user.

Also if I was contributor to kernel of Linux (I sadly aren't, as it isn't my field or expertise + skill issue), genuinely speaking i would much much more care that my operating system I am creating or using would jump above that 2% of market share (and probably even lower for normal users) and ideas like that, that some want to say to 80% of market with dGPUs "go F yourself" is... malicious in action.

I can agree module shouldn't use EXPORT_SYMBOL_GPL. But it is not breach of license (it only happens during distribution) it is more like "breaking gentleman's agreement". But at the same time setting general purpose buffer like DMA_BUF as GPL only symbol (like it happened in the past) is simply malicious action that says hey we don't want Linux to be popular.

The most important thing in ANY software is that software is used, copyright is useless if no one uses software you create. And I at work in my field I want my software to have real use. This is why Microsoft despite knowing who is pirating Windows, doesn't call police to anyone doors in general, because some level of piracy is small price to achieve market monopoly - and this is not gray area, if caught by police it would be 99% score guilty.

All I want from linux is that decisions like that are done on technical/practical merit. Yes you can make life of Nvidia hard and simply push on Nvidia work with maintaining their driver against kernel releases and marking kernel as tainted. I have no issue with that. That is reasonable as you can't debug stuff or fix issues that aren't yours. So if Nvidia continues walking that way, you can basically (as linux contributor) close door and say report issue to Nvidia. That is again reasonable. Closing door at all for Nvidia to make it impossible to work in Linux world is not reasonable.

[mSparks]

mSparks there is a particular reason why Nvidia wants access to the EXPORT_SYMBOL_GPL instead of using the EXPORT_SYMBOL versions. In general the EXPORT_SYMBOL_GPL versions are slightly faster because they don't have to maintain any form of legacy module compatibility.

Putting aside the fact that its pretty much established they only use EXPORT_SYMBOL_GPL at compile time to make sure they are not using EXPORT_SYMBOL_GPL, and additionally to avoid a failure related to a linux kernel module failing when it calls an EXPORT_SYMBOL_GPL.

And the rest of the accusations have no more validity then some imaginary person saying:

It has recently been brought to my attention that Christoph Hellwig has been copying source code from a windows source leak and pasting it directly into the Linux kernel, marked as GPL_ONLY

Then expecting us to prove it wrong.

1. What is wrong with them doing so from their own GPL code
2. Why should this be stopped at all costs, costs that include preventing high bandwidth PCI cards from supporting linux and completely breaking open source openGL and ZFS code?