NVIDIA Transitioning To Official, Open-Source Linux GPU Kernel Driver

[Sevard]

Quick question: how do you handle distros not signing the nvidia blob? Do you build your own kernel so you can use your own cert there as well?

He installs self signed cert. It kills idea of SecureBoot, but it works.

[sinepgib]

He installs self signed cert. It kills idea of SecureBoot, but it works.

Hmmm, the idea is that a third party doesn't tamper with your setup. You can perfectly keep that cert in, say, a FIDO key that is relatively secure. I don't think how it kills the idea.

[sinepgib]

I think it's NV who should ask them to do so. And NV prefers to use self signed certs for this and that kills whole point of using SecureBoot.

AFAIK you can have stuff signed multiple times, can't you? NV will have its signature for firmware, but it doesn't stop signing the modules so the kernel can load them, or does it?
I may be confused about it, but being a signature rather than encryption should allow that.

[L_A_G]

I don't about guilt, but you need to be ashamed. So much money for single gpu

Well in my defense I did buy it at a moment where scalpers thought "Oh sh*t, the market's soon going to be flooded with actually available stock" and got it at basically MSRP. The idea was that I'd have some fun with it and then sell it at possibly a profit a few months down the line. Which I did but the buyer thought the coil whine (which all top end 3000-series cards suffer from) meant it was broken and it came back like a boomerang with a demand for his money back. Got it replaced under warranty (which Nvidia will do, but only once) and the factory-new thing (i.e I didn't get someone else's return) was actually worse.

I probably could still sell it for almost exactly what I paid, but I don't want to deal with it coming back again like a boomerang with an angry buyer claiming that I'm trying to scam them again.

[birdie]

Linux Action News 240: NVIDIA has announced its plans for an open-source GPU driver. Christian Schaller, the Director for Desktop, Graphics, Infotainment and more at Red Hat, gives us the inside scoop on this historic announcement.

https://linuxactionnews.com/240

[qarium]

Well well well i did write about nvidia will opensource their driver long long time ago...

the people are now positive about nvidia but there is no reason for this here is why:

CLA WAR same shit as KDE i used KDE or like 18 years i am now on Gnome CLA WAR alone proof they are enemy of opensource

AMD did go the way of opensource kernel driver and opensource userspace driver and small firmware
Nvidia instead did build a very very big Firmware so in the end they will move any "secret" into the firmware.

No userspace driver YET and if we use AMD as reference it nearly took like """10 years""" to build a competive open-source driver...
This means anyone who are interested in opensource driver can just drop Nvidia for 5 or more years...

the opensource kernel driver change nothing about the walled garden vendor lock in like CUDA and NvidiaGL(openGL code who only run on Nvidia hardware) and other Nvidia anti-competition technologies like DLSS ...
people should be happy if CUDA goes opensource... and other companies can make GPUs with the ability to run closed source CUDA apps...

Any opensource driver who is not upstream YET is useless people should not buy Nvidia hardware the next 5 years and should wait until the code is upstream...

[oiaohm]

• Modules signing? It's distros' job which willingly decided not to do that because reasons. Nothing technically prevents RedHat/Fedora/Suse/Ubuntu from building kernel modules and signing them.
• I was around 2000, in fact I started using Linux around 1998 and I don't remember anything about NVIDIA in terms of open sourcing something and giving up on that. I cannot find anything on Google either.
• Patent issues? What??
• Supercomputer contracts? Sources? Proofs? Not some hearsay, please.

Patent issues are a simple one to show.

https://openinventionnetwork.com/linux-system/

This is the open invention network patent patent pool what it covers. Nvidia is not a member of. Yes this patent pool only requires open source license support that is kind of compatible with the Linux kernel. When I say kind of compatible nothing to add a patent to the patent pool says the code has to support the Linux . There is no requirement for patents added to this pool to support closed source modules. The patent pool was designed to be licensed compatible to patents from 1995.

The patent issue does stuff you around with kernel module signing. https://wiki.debian.org/NvidiaGraphi...ion_470.103.01 There is a reason why distributions are going DKMS. Some of this is they don't have the patent license to valid build the Nvidia drivers so they push this on to the end user. Yes since distribution cannot build Nvidia module because its not totally GPL compatible they end up not being able to sign the module.

The fact is that Linux kernel lacks stable API and comes under a very communism-like license is not a testament to "issues" in NVIDIA drivers

This problem is way worse than you think. Linux kernel has patent issue that make doing a stable driver ABI complex. Redhat for these distribution have done a restricted kernel features for a stable driver ABI and they do run into cases where they cannot have particular features that the Linux kernel mainline has because they do a stable ABI from kernel space for third party drivers. The reality here you have ignored the issue Redhat Kernel Application Binary Interface runs into this includes patent problems so not being able to expose X features because they provide a stable binary driver features. Yes there is reason why the Linux kernel has got runtime protection against linking against GPL only protected functions by non GPL code 2020 there is a legal issue with patents and software licences here. Yes this issue has been known about since 1995.

The two most significant Linux kernel applications which are RHEL and Android both do not use the vanilla Linux kernel. It speaks volumes about the whole situation we are discussing here.

https://android.googlesource.com/kernel/common/+/refs/heads/android-mainline/README.md

Do not send patches upstream that contain only symbol exports. To be considered for upstream Linux, additions of EXPORT_SYMBOL_GPL() require an in-tree modular driver that uses the symbol -- so include the new driver or changes to an existing driver in the same patchset as the export.

You need to stop using this idea. Yes Android kernel developers don't want to touch symbol exports at all yes this is due to the legal issues this is why this is in their readme for their kernel. So the kernel ABI to drivers is not something android kernel developers are highly interested in when it comes to legal. Yes legal rulings on exports Android kernel developers push back on upstream Linux kernel at kernel.org. You want a ruling on a exported function from the Linux kernel this is kernel.org mainline area. This is also true for RHEL. So your statement about do not using the vanilla Linux kernel is true and false. The vanilla Linux kernel is used by RHEL and Android for ruling on what the legal status of functions exported by their kernels are then their kernels conform to these rulings so indirectly used vanilla kernel this is why its true and false its true they don't ship vanilla kernel but its not true they are not using the vanilla kernel for a critical part of the process. Without the upstream rulings you have zero exported ABI from either of the Redhat or Android kernels.

There is a lot more complexity here than one likes. Between GPLv2 only licensed stuff and patent licenses over the Linux kernel only having to be for GPLv2 licensed code this does make supporting closed source linux kernel modules a legal mine field. This is very different to the Microsoft and Apple location.

CDDL of ZFS at least could be argued at least conforms to a term of OIN this is something the Nvidia kernel module did not have.

Please note the link that was in my prior post points to a issue where something is exported by the upstream kernel that first is ruled ABI safe for non GPLv2 code to use then when another feature is added to changes from non GPLv2 code compatible to GPLv2 only compatible. This is the core that ruins exporting stable kernel ABI from the Linux kernel over and over again. Yes a legal problem. This legal problem first turned up in 1995.

Yes there are features used in Linux kernel space that cannot be exported to Linux userspace legally. There is in fact a legal need for Nvidia and anyone else doing a kernel module that exports stuff to userspace to in fact open source their driver with Linux to allow the driver to be inspected and legal issues to be found and corrected. Yes kernel functions changing from non GPL to GPL only have caught out items like ZFS as well this is not just because Nvidia was releasing a closed source driver that this legal problem has been turning up. Out of tree drivers for Linux that are not GPLv2 compatible licenses have all over time run into this legal problem.

The legal environment of the Linux kernels is massively different to Microsoft and Apple. Having thousands of different companies submitting code with different items they have patented and licensed is what creates the Linux kernel legal nightmare. Having the development module like Linux kernel with the license the Linux kernel has is what creates this problem. Yes the license is why some of these companies are willing to submit code to Linux kernel yet not to BSD based solutions..

Yes the legal nightmare was known as early as 1995 and the Linux kernel developers started telling people you need to mainline you drivers. Due to their being a legal need to mainline your drivers this undermines any reason to maintain a stable exported ABI for drivers.

Parties like Nvidia have been taking that the Linux kernel developers only want the driver open source and mainline completely missing there is a legal need that if it not done causes major on going problems due to how complex the legal environment of the Linux kernel is due to all the different companies submitting code and having different ideas on how stuff will be licensed with patents and code.

birdie get now why there is no way to fix the problem the way you keep on pushing. There are too many parties you need to have in absolute agreement for non GPLv2 compatible code with the Linux kernel in kernel space for this to happen dependable way. At some point you just have to accept the reality of the problem. Horrible the only solid working solution is open source and mainline this is not that parties have not tried other solutions just they don't legal work in the end.

[tuxd3v]

Nope won't happen and it is a good way for it to be that way! Pascal lacks the hw and no one in a comercial Enterprise should be allowed to waste $ towards the past.
I completely understand birdie's rants about oss module but medium to long term nv is going to spend less with an oss reference module.

There are still a lot of people with Pascal cards me included.
I understand that they don't want to burn money with cards that are not on the market already, but in that case we are left only with the proprietary driver.
Not even nouveau, supports Pascal

[zboszor]

Honest question:

Does anyone who posts here actually use the vanilla kernel?

(Me puts up hand.) I am in the POS and fast food franchise industry, maintaining the OS for a lot of hardware (literally many tens of thousands of sites with multiple computers in one location), using a Yocto based OS and an almost vanilla kernel built from sources with module signing enabled. No NVIDIA based hardware in sight. Everything is AMD or Intel. While the desktop Linux presence may be low, we have very strong figures in the POS space.

[zboszor]

And check MacOS and Linux vanishingly tiny market shares for what matters, i.e. gaming.

What do you do for a living if only gaming is what matters to you? Gardening?