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

[Khrundel]

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

Thank you, it is quite informative.
First of all, that old Linus response: it clarifies all these "GPL violation" nonsense. Well, it was at least coherent. I mean these old rant against private modules, if you believe in copyrighting of function names than you can consider any private module "derived work" because it calls or implements functions and so it violates GPL2. Unfortunately for them, it is not only immoral to do this, while pretending to be against abuse of copyright law, but also now there is a precedent, case Oracle vs Google, where US supreme court declares using and implementing API is a fair use. So no, private modules do not violate GPL. Private modules are legal.

Next funny thing is that email from 2020. "Ah, the proven-to-be-illegal "GPL Condom" defense"... Why mention it? I don't ask why lie, just why mention? I mean if something is illegal, why not sue them? If you dont want, why mention? For me it is obvious, you are writing such when you know your patch is very questionable, so you are preparing for critique pretending your victim is even worse and deserves it.

Next thing, ironically if anyone is violating DCMA it is that Christoph guy. DCMA criminalizes any help in violating copyright, so, assuming private modules violate GPL, Christoph, who believes private modules violate license, intentionally mark some symbols as available to private modules helps in violating. He endorses violation, making people to believe they do legit stuff when importing EXPORT_SYMBOL only.

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.

You are misrepresenting nvidia point.
Nobody claims something removes GPL, that is strawman.
They just work within limits of GPL, if you want GPL code within kernel module - they've written it. Yes, this is not kind of code people like Christoph want, but they have no right to force nvidia to do what they want.

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.

No. Nvidia module acts withing GPL.

These changes should cause Nvidia drivers zero issues if they are not doing the wrong thing.

That is not true. I mean it looks legit on a first glance, but remembering DMABUF issue... This is just excuse to their malicious behavior. The whole idea about ability to somehow debug kernel module, well, nobody will debug any GPL out-of-tree driver and nobody can debug some GPL driver which interacts with device's firmware. Or with hardware. So, whole idea of special API for GPL is dumb, it will never work. I bet it is a clever trick of FSF zealots who tried to ban nongpl modules before and failed.

[mSparks]

Next funny thing is

I think the funniest way this can pan out is that this patch is accepted in mainline
and then a patch stripping out any GPL_ONLY marking is also accepted
on the same kernel release.

[qarium]

It's used for more than just AI, and 24GB is enough for 99% of what my lab do (I'm an outlier, because I do regularly need 48GB of VRAM, but the things I study are much larger than normal).
For raw costs, and with some careful timing, a 7900XTX 24GB would cost me not much more than a Quadro A4000 16GB, while in terms of raw compute outperform it dramatically. But it's not an option, as AMD compute support isn't there... (I am not spending $$$$ on something which may or may not work, so official support is required).

if you need 48GB vram anyway then the AMD PRO W7900 should be fine for you.

i have a vega64 and a W7900 i can say to you on fedora 38 if you use dnf install rocm* HIP works in blender als also OpenCL works.

also about "official support" it is 100% sure that the AMD PRO W7900 is 100% official supported in ROCm/HIP...

[oiaohm]

That is not true. I mean it looks legit on a first glance, but remembering DMABUF issue...

There is a key question you did not ask. Who developed DMABUF that was Intel and AMD. Who had flagged the DMABUF interfaces before Nvidia even used them as GPL only again Intel and AMD. Who was not paying Intel and AMD for the patents over DMABUF technology that right Nvidia. Yes part of agreement to remove the GPL only flags off DMABUF was a payment from Nvidia to AMD and Intel.

Oracle vs Google did not prove kernel modules were legal. In fact google changed the way drivers could be done for Android after that case because it does not rule the way you think it does. The case ruled you can re-implement the API/ABI without legal risk. But it did not rule that you could use the existing against it license.

Yes android KMI does not include any EXPORT_SYMBOL_GPL.

https://source.android.com/docs/core/architecture/kernel/abi-monitor

The GKI kernels use the TRIM_UNUSED_KSYMS=y and UNUSED_KSYMS_WHITELIST=<union of all symbol lists> configuration options, which limit the exported symbols (such as symbols exported using EXPORT_SYMBOL_GPL()) to those listed on a symbol list. All other symbols are unexported, and loading a module requiring an unexported symbol is denied. This restriction is enforced at build time and missing entries are flagged.

Yes the filter that just being added to mainline Linux kernel had been in the android kernel since the Oracle vs Google case because that case said the same problem. Sorry the Oracle vs Google case result says implement this lock-down and google already has with the Android kernel done a different way.

[oiaohm]

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

No that post is personal option not the legal one is that 2006 post,.
https://yarchive.net/comp/linux/export_symbol_gpl.html Yes 2005 instead of 2006.
That the Linus Torvald post after talking to legal in 2005. Yes that is refering to EXPORT_SYMBOL_GPL and it effect on license enforcement.

Linus Torvald you have to be careful most of the time it his personal option how it should work not the legal reality. The legal reality closed source modules should stay well clear of EXPORT_SYMBOL_GPL.

Please note this is before DMCA existing. DMCA is designed to enforce Intent. "Intent matters a LOT." is more true today than 2005.

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.

There is more to this.

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.

Remember Intel and AMD both developed DMA_BUF they both allowed their patent techs to be used. Nvidia paid nothing to the development of DMA_BUF. Guess what here Nvidia said since DMA_BUF was Linux world only they did not need to pay for the patents around DMA_BUF so AMD/Intel could not use DMA_BUF patents to offset their patent payment to Nvidia.

Remember 80 percent of computers don't have dGPU. Nvidia the less than 20 percent that gets the most revenue was the party who was not paying for development of different Linux things. Party who paid for development of items has the right to license it how they see fit. Nvidia does not have a magic right to break those licenses. Yes the removal of EXPORT_SYMBOL_GPL off of many DMA_BUF symbols came after Nvidia agreed to accept that DMA_BUF releated patents were real patents so AMD/Intel could use those to off set patent cost.

[oiaohm]

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.

EXPORT_SYMBOL_GPL start off as a compile time check because it was believed modules would not be dynamically loading. Google with the Android kernels started enforcing EXPORT_SYMBOL_GPL blocking on kernel modules at runtime due to driver developers doing the wrong and using dynamic symbol loading to get around the blockin only 2018.

"What is wrong with them doing so from their own GPL code"
Lets say Nvidia open sources their driver completely and its not a mainline kernel driver even if it GPL licensed it still a really bad idea to use anything tagged EXPORT_SYMBOL_GPL without attempting to mainline the driver because mainline Linux developers presume everything using that is in the mainline kernel or at least being posting on LKML for mainlining.

Copyright is part of the problem here. The other part is EXPORT_SYMBOL_GPL other meaning is mainline kernel function to only be used by parts include with the mainline kernel. Yes anything tagged with EXPORT_SYMBOL_GPL has lower restrictions on change compared to the plain EXPORT_SYMBOL.

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?

EXPORT_SYMBOL_GPL does not break the open source opengl driver stacks even with enforcement.

To be able to do security patches and so on you do need area of code that 100 percent under the core kernel developers control. Using EXPORT_SYMBOL_GPL functions in third party modules effectively is messing up the line of this is core kernel developers and third party module developers. If third party modules were allowed to call what ever functions they like the result could be the Linux kernel unable to develop at all. Yes Microsoft signed driver program is also about stopping third party drivers developers for using Internal windows functions and then demanding that Microsoft kernel developers cannot change them because they break their driver.

Basically mSparks there need to be clear lines of who is responsible where. One of those lines in the Linux kernel is the EXPORT_SYMBOL_GPL and EXPORT_SYMBOL.

[mSparks]

Lets say Nvidia open sources their driver completely and its not a mainline kernel driver even if it GPL licensed it still a really bad idea to use anything tagged EXPORT_SYMBOL_GPL without attempting to mainline the driver because mainline Linux developers presume everything using that is in the mainline kernel

Could you give me an example of why its such a bad idea.
lets pick "one at random"

why does
"mainline Linux developers presume everything using ktime_get() is in the mainline kernel"

matter in any way shape or form?

And wouldn't something like
EXPORT_SYMBOL_UNSTABLE be a much better idiom for "using this is a bad idea".

[oiaohm]

"mainline Linux developers presume everything using ktime_get() is in the mainline kernel"

https://docs.kernel.org/core-api/timekeeping.html

Note the stack of deprecated but that the tip of the iceberg.

matter in any way shape or form?

It matters.

Now from the timekeeping link as the following always been what ktime_get() equals?

Useful for reliable timestamps and measuring short time intervals accurately. Starts at system boot time but stops during suspend.

The answer is no. The first version of ktime_get() in fact equals ktime_get_boottime() where it did not stop during suspend and there is even 3 other different forms of ktime_get().

Yes the core-api timekeeping functions due to be EXPORT_SYMBOL_GPL like all other EXPORT_SYMBOL_GPL functions can be refactored without notice using a semantic patches even in a LTS branch point release. So ktime_get() like every other EXPORT_SYMBOL_GPL function in a random point version update could magically up and disappear. Remember semantic patches changing functions names and the like is find as long as all source code using those functions are processed. This is why it so dangerous for end users if third party drivers put their hand in the EXPORT_SYMBOL_GPL cookie jar because the functions tagged with that can change how the operate without notice even completely disappear without notice.

EXPORT_SYMBOL_UNSTABLE be a much better idiom for "using this is a bad idea".

That was tried back in the 1990s to early 2000 but third party driver developers ignored it more than EXPORT_SYMBOL_GPL. The reality you want to use what ever name for unstable items that developers ignore the least. The threat of DMCA/GPL is helpful to stop developers using symbols they should not.

Yes even without the possible DMCA/copyright issues its a bad idea to be using any function tagged EXPORT_SYMBOL_GPL in a third party module particular when you wake up that EXPORT_SYMBOL_GPL replaced EXPORT_SYMBOL_UNSTABLE.

So using ktime_get() might give you correct value or might not there is no stability promise on EXPORT_SYMBOL_GPL because it is EXPORT_SYMBOL_UNSTABLE. Yes this is why if third party driver is needing something that is tagged EXPORT_SYMBOL_GPL the function either need to be changed up mainline to EXPORT_SYMBOL or a new function/wrapper added that is EXPORT_SYMBOL.

The fact the function due to being EXPORT_SYMBOL_GPL is valid to disappear without notice if the block of load causing driver to fail the driver code was wrong.

I guess you were pulling the Oracle case. Do note that the ktime_get() symbol from its introduction to the Linux kernel today it always been tagged EXPORT_SYMBOL_GPL and there have been different glitches in the Linux port of dtrace caused by the use of it.

This is one of the things OpenZFS with floating point was one of the insanely rare cases were a function was not marked as EXPORT_SYMBOL_GPL before third party driver developer used it. But there was a upcoming refactor to remove a locking issue caused by the old floating point system in kernel space. Please note for the complete time Linux has existed it also been highly recommend that third party driver developers never use floating point in kernel space..

[Khrundel]

There is a key question you did not ask. Who developed DMABUF that was Intel and AMD. Who had flagged the DMABUF interfaces before Nvidia even used them as GPL only again Intel and AMD. Who was not paying Intel and AMD for the patents over DMABUF technology that right Nvidia. Yes part of agreement to remove the GPL only flags off DMABUF was a payment from Nvidia to AMD and Intel.

But this clearly contradict what you stated before, ie gpl only exports are not required for driver to function, they just work a little faster bypassing some checks.
You should pause for a minute and choose your ground. You may still insist on GPL only as a mechanism for keeping kernel stable, but you'll have to admit this case was a grave abuse of this mechanism, accepting dmabuf API as gpl only export should never happen in first place, patented API, even if you believe in such nonsense, should have no place within free kernel. Longevity of this crisis and fact that AMD and/or Intel have extorted some money should show all these gpl export just doesn't work as intended and should be removed instead of forcing.
Also, words of Christoph, i.e. "tainted" and "proven to be illegal" show this is nothing to do with easing of debugging, they clearly insist on forcing nvidia to stop linux support. So my version, about corruption within kernel team looks more credible.

Oracle vs Google did not prove kernel modules were legal. In fact google changed the way drivers could be done for Android after that case because it does not rule the way you think it does. The case ruled you can re-implement the API/ABI without legal risk. But it did not rule that you could use the existing against it license.

Are you in right mind?
GPL clearly allow using any interface of GPLed software, you won't be able to run any non-GPL software on linux if just calling a function from GPL library or system call from GPL kernel would require GPL license from caller.
All this "closed source kernel module is illegal" came from idea that kernel module should implement some intefrace to a kernel module and this interface is a part of GPLed kernel so any kernel module is either derived work of kernel and thus shall be released under GPL2 or it is pirated software using part of kernel (interface) without license.
Google v Oracle say you don't need a license to implement some inteface (API/ABI). That's it, period. Out of tree kernel modules are not derived work of kernel, they are separate software products just implementing/using required interfaces following fair use rules.

Yes android KMI does not include any EXPORT_SYMBOL_GPL.

Well, maybe some time you will understand that letters within macro name hold no legal meaning. Just read the GPL2.txt. Thats it, it is the exhaustive list of things GPL2 requires. Being a copyleft license it does not recognize some central "upstream" repository, it considers every fork equal so the whole intention behind GPL2 is a protection of the rights of former contributors from arbitrary will of future contributor. GPL forbids adding any additional requirements. EXPORT_SYMBOL_GPL holds same legal power as a comment saying "and also GPL requires every user of this software to name his/her firstborn son after me".

[mSparks]

https://docs.kernel.org/core-api/timekeeping.html

Note the stack of deprecated but that the tip of the iceberg.


It matters.

Now from the timekeeping link as the following always been what ktime_get() equals?

The answer is no. The first version of ktime_get() in fact equals ktime_get_boottime() where it did not stop during suspend and there is even 3 other different forms of ktime_get().

Yes the core-api timekeeping functions due to be EXPORT_SYMBOL_GPL like all other EXPORT_SYMBOL_GPL functions can be refactored without notice using a semantic patches even in a LTS branch point release. So ktime_get() like every other EXPORT_SYMBOL_GPL function in a random point version update could magically up and disappear. Remember semantic patches changing functions names and the like is find as long as all source code using those functions are processed. This is why it so dangerous for end users if third party drivers put their hand in the EXPORT_SYMBOL_GPL cookie jar because the functions tagged with that can change how the operate without notice even completely disappear without notice.


That was tried back in the 1990s to early 2000 but third party driver developers ignored it more than EXPORT_SYMBOL_GPL. The reality you want to use what ever name for unstable items that developers ignore the least. The threat of DMCA/GPL is helpful to stop developers using symbols they should not.

Yes even without the possible DMCA/copyright issues its a bad idea to be using any function tagged EXPORT_SYMBOL_GPL in a third party module particular when you wake up that EXPORT_SYMBOL_GPL replaced EXPORT_SYMBOL_UNSTABLE.

So using ktime_get() might give you correct value or might not there is no stability promise on EXPORT_SYMBOL_GPL because it is EXPORT_SYMBOL_UNSTABLE. Yes this is why if third party driver is needing something that is tagged EXPORT_SYMBOL_GPL the function either need to be changed up mainline to EXPORT_SYMBOL or a new function/wrapper added that is EXPORT_SYMBOL.

The fact the function due to being EXPORT_SYMBOL_GPL is valid to disappear without notice if the block of load causing driver to fail the driver code was wrong.

I guess you were pulling the Oracle case. Do note that the ktime_get() symbol from its introduction to the Linux kernel today it always been tagged EXPORT_SYMBOL_GPL and there have been different glitches in the Linux port of dtrace caused by the use of it.

This is one of the things OpenZFS with floating point was one of the insanely rare cases were a function was not marked as EXPORT_SYMBOL_GPL before third party driver developer used it. But there was a upcoming refactor to remove a locking issue caused by the old floating point system in kernel space. Please note for the complete time Linux has existed it also been highly recommend that third party driver developers never use floating point in kernel space..

OK, great. yes, exactly the oracle case,
Given we are a decade in now to Oracle using

https://mjg59.dreamwidth.org/31357.html

A function called dtrace_gethrtimer() simply returns the value of ktime_get(). dtrace_gethrtimer() is exported via EXPORT_SYMBOL() and therefore can be called from the DTrace module.

And none of your hypotheticals materialised, or mattered

Do you have a worked example of one that can be used in the sentance

EXPORT_SYMBOL_GPL like all other EXPORT_SYMBOL_GPL functions can be refactored without notice using a semantic patches even in a LTS branch point release. So ktime_get() like every other EXPORT_SYMBOL_GPL function in a random point version update could magically up and disappear.

in place of ktime_get but where it did matter.

presumably one that would take more than 5 seconds to replace if it did "magically up and disappear."

(Because, otherwise, it looks a lot like you just made all that up and it has no basis in reality)