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

[mSparks]

http://dtrace.org/blogs/ahl/2011/10/...e-for-linux-2/
2011 Oracle Linux Dtrace is CDDL by the way.

2017 is when Oracle changes their DTrace from CDDL with SPL wrapper to GPL compatible licenses. Oracle never released a Linux version of Dtrace that was in fact closed source.

There is no such thing as a closed source blob of Dtrace it never existed mSparks. Dtrace the issue is license incompatibility between GPL and CDDL from 2011 to 2017 on Linux. Yes 2011 dtrace on Linux was a buggy mess. Orcale did not start dtrace on Linux until 2011,

mSparks Dtrace is one of those things. Sun never released a closed source version of Dtrace, Oracle Never released a closed source version of Dtrace. Dtrace has not always been under a GPL compatible open source license but Dtrace has always been under an Open source license.

Also old versions Dtrace that are not GPL compatible on Linux will not have a problem with the change why because they will not work due to other changes in the Linux kernel on the kernel version that has this change.

So remind me why is it OK for Christoph Hellwig to break it by nerfing the kernel functions it calls?

[oiaohm]

So remind me why is it OK for Christoph Hellwig to break it by nerfing the kernel functions it calls?

There is a deeper question.

Solaris porting layer that openzfs uses and early dtrace uses has not been nerfed by Christoph Hellwig actions. The floating point issue that OpenZFS run into is a difference between Linux kernel and the Solaris one. Linux kernel you are not meant to use floating point in kernel space and Solaris kernel allows it leading to no matching Solaris API.

Solaris porting layer the wrapper code on Linux is all GPLv2 the main Linux kernel license.

Where things come problem with dtrace is that different wrappers were in fact written in CDDL.

Remember CDDL and GPL are not compatible license..

All Christoph Hellwig is doing is implementing a technical measure that traces derivative work as per law. A GPL wrapper function that is in line with law as you find in ndiswrapper and Solaris porting layer (I could give many more examples) his alterations would not trigger on.

Remember these wrappers have a overhead.

EXPORT_SYMBOL int some_solaris_func(void* some_solaris_args){
    return GPLlinux_func()
}

Take the code above simple question is this code above in fact legal if this code is GPL licensed for a non GPL licensed work kernel module to use the some_solaris_func. At first some would presume yes for non GPL licensed work to use. They answer is a horrible no its not in all cases. What goes wrong the compiler decides to optimize out the some_Solaris_func and replace it with GPLLinux_func.

The derivative work laws is a pain. Yes you need to remember at times to add flags to say to compiler do not optimize here. The technical measure that Christoph Hellwig has added will trigger on when it wrong but will not trigger when it right.

symbol_get means you are get getting a direct GPL function pointer no wrapper. Yes if the wrapper is using a direct GPL function that using it means you code has to be derivative work you code should also be GPL compatible license.

Yes some_solaris_func could be some dtrace_func then you notice that the wrapper in early Linux dtrace is CDDL you now have a incompatible license problem.

Yes in the end Oracle came around and worked out opps most of their dtrace kernel code with Linux turns out to be Linux kernel derivative work that why over 2017 dtrace for Linux is GPLv2 with Linus exception.

There is a unique problem with Nvidia. Dtrace and OpenZFS we have a API/ABI that is not Linux as in some other OS to write GPL code to provide that APi/ABI then use closed source/gpl incompatible past it.

Where is Nvidia non Linux API/ABI(not GPL tainted) for its closed source driver to be using this is absolutely not documented. So there is a high risk that Nvidia has GPL derived code inside their closed source kernel module because they never drew a line to work to.

Dtrace and OpenZFS is been possible to find where the line in the sand that being a GPLv2 derivative work ends. Of course Oracle developer doing early Linux dtrace was not careful on where this line was. Nvidia closed source there is no clear line in the sand where GPlv2 derivative work ends.

There is a old AIX file system driver that was in the Linux kernel that also implemented AIX API in GPLv2 code and core driver code is open source but its license is also not GPLv2 compatible yes its marked as a proprietary module and it in the main kernel tree and none of Christoph Hellwig changes cause this driver to fail. Yes there is a example in the Linux kernel source how to do a proprietary module correctly.

[mSparks]

none of Christoph Hellwig changes cause this driver to fail.

well, we'll see. its not in the wild yet afaik.

[oiaohm]

well, we'll see. its not in the wild yet afaik.

I have already build the kernel with the with the Christoph Hellwig changes with the old AIX file system driver I need it for dealing with archive stuff. You might not have seen it in the wild but I have already.

[Eriks]

Looks like Nvidia 545.23.06 driver works just fine with Linux 6.6

[rabcor]

The correct response would just be to go the open source driver route tbh, like amd did with amdgpu. Honestly what's even stopping them from doing that at this point? they can just keep some of the stuff they wanna keep close to their chest like nvapi and cuda proprietary, just make them separately installable proprietary modules for an open source driver. They have nothing to lose and a lot to gain from opening up their driver.

Also this isn't needless hostility, nvidia using gpl code in their proprietary drivers is illegal, nevermind "shouldn't", it actually "isn't" allowed. Except the law only exists to protect the big guy like nvidia and not the little guy like bob the oss coder, so even if it is illegal, nvidia can always get away with it. That the linux kernel devs take issue with that? being that they're guys like bob the oss coder? It's not a surprise.