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

[mSparks]

Nvidia proprietary drivers are PITA.

How, exactly?

I've been on akmod-nvidia as a daily driver for like 15 years now, through like maybe 5 different distributions, and never once had any problem with it. just (generally) continually improves, both in performance and in decreasing bugs.

vs, say gnome,
That blows up important shit every 6 months.
That's a nightmare, not as big a nightmare as windows, but just this gnome 44 they just broke fullscreen windowing.

or AMD GPUs, that have most graphics applications bug report systems full of their issues.

Nvidia is playing with fire here and making their users pay for it.

Who?, exactly, which users?, in which module?, and why is it "so important"?

[gnattu]

https://arstechnica.com/gadgets/2021/09/android-to-take-an-upstream-first-development-model-for-the-linux-kernel/

The android kernel is a more complex one. Yes at first android kernel got more hardware support but then the nightmare came since source code had not be shared when security flaws were found updating the software for security came impossible.

Yes you are right on the upside of allowing closed source drivers that hardware support comes sooner but you missed the very big downside. Security is poorer in the non GPL enforced model. Yes google with the Android kernel has been forced to admit defeat and start saying to vendors if you don't open source and upstream your kernel drivers don't be surprised if your hardware ends up not supported by Android because it too security problematic.

Please note de-blobbed libre-kernel removes items that with at stock Linux kernel GPLv2 are truly classed as independent works. Device firmware blobs operate without needing the Linux kernel. This is not the case for Nvidia Linux kernel drivers they do operate using features of the Linux kernel so are not truly independent works.

You can argue for the downsides, but this does not change my point. Most hardware vendors do not like GPL and do not want everything to be open-sourced. Convince the vendors, not me the person who pointing out this sad fact, that you should open-source the driver. As you said, device firmware blobs operate without needing the Linux kernel, which makes the vendors legit to put as much functions as they want into the firmware. Nvidia has an open-sourced kernel module and that module did exactly this. Most of the functions are hidden in their firmware and the driver is more likely a protocol to talk with the firmware than a driver that controls the hardware, and Nvidia is not the only vendor doing this. The beloved Raspberry Pi's GPU has its own RTOS running on it and the Linux kernel GPU driver is merely talking with the other OS. If the logic is too complex for the firmware, how about just throwing the interrupts into the user-space and just shipping a closed-source user-space binary? The kernel cannot enforce the user-space binary to be open-sourced because the user-space is not the derived work. All examples above comply with the GPL license and being open-source. You would consider this is a FOSS victory and great, healthy and secure implementation? Obviously, no. Other hardware vendors not caught like Nvidia probably not because they are more open-source friendly, but hiding their code better.

[creative]

timofonic Some of your post I agree with.

mSparks Very few problems here as well, nvidia has been good. Tried AMD GPU had issues with a lot of older games. Read posts of users playing games with older graphics API's with issues, proved to be not a very good alternative for me, thought it was just the GPU I got, turned out it's very common even in Windows. They do great with DX12 and some DX11 but once you start moving further back it can get bad. Also driver timeouts or hangs.

I'm all for AMD, I'm on X570 with a 5800x, it has been great. On the GPU side of things though, a lot and I mean a lot is lacking concerning AMD, and with the most important thing their GPU's aim at, gaming. Like I said, they do good with brand new games but older stuff, bad. When it comes to my gaming library I don't want to feel like I'm rolling the dice when firing up older games.

[braiam]

Who?, exactly, which users?, in which module?, and why is it "so important"?

I'm literally linking the post I'm referring to.

Past issue caused by Nvidia driver miss using EXPORT_GPL_ONLY have include harddrive data corruption caused by using EXPORT_GPL_ONLY functions that had changed and this will happen again if Nvidia allowed to get away with doing this.

Please note Nvidia miss behavior with internal only functions is not just restricted to Linux. Nvidia has been caught by Microsoft using Windows internal only functions as well and also caused users to have their hard-drive to have data corruption because of these actions the Microsoft requirement for driver inspection did come about because of this. Yes items of the Linux kernel flagged as EXPORT_GPL_ONLY need to be treated as internal only functions that only the Linux kernel and the drivers that ship with it can use.

[mSparks]

I'm literally linking the post I'm referring to.

->data corruption caused by using EXPORT_GPL_ONLY functions that had changed

That doesn't sound like an nvidia issue, that sounds like a "EXPORT_GPL_ONLY function" issue, why wouldn't this manifestation affect any else using them?

->Nvidia has been caught by Microsoft using Windows internal only functions as well and also caused users to have their hard-drive to have data corruption because of these actions the Microsoft requirement for driver inspection did come about because of this.

Absolute bullshit. Microsoft write internal windows functions specifically for NVidia.
Heck, MS have a history of writing and rewriting internal windows functions just for games if they are popular.
e.g.

https://arstechnica.com/gadgets/2022/10/windows-95-went-the-extra-mile-to-ensure-compatibility-of-simcity-other-games

They actually want competent hardware and software vendors support on their platform.

There is a very vocal minority who do not want the same for Linux, which is a shame.

[citral]

Hacking stuff and making exceptions for buggy games is not something to brag about tbh. It is what it is, and is needed unfortunately, like usb quirks and such, but it's sad.

[mdedetrich]

And they do, they aren't marked with the marked with EXPORT_SYMBOL_GPL but with EXPORT_SYMBOL. Those marked with _GPL have zero guarantee, because those symbols are used for in-tree drivers.

There's a good article explaining with Linux devs and Linus himself believe that if it ever goes to court, they would have it in the bag. https://lwn.net/Articles/154602/

That's not what is meant a stable in kernel ABI. A stable ABI is stable across multiple kernel versions

[braiam]

->data corruption caused by using EXPORT_GPL_ONLY functions that had changed

That doesn't sound like an nvidia issue, that sounds like a "EXPORT_GPL_ONLY function" issue, why wouldn't this manifestation affect any else using them?

There's no guarantee of stability of EXPORT_GPL_ONLY functions. EXPORT functions however have a stable API and they are documented. if you don't use them, that's your issue, not the kernels.

[oiaohm]

how about just throwing the interrupts into the user-space and just shipping a closed-source user-space binary

This end up in a Microkernel design. Turns out microkernel designs with drivers in userspace you don't end up with major disasters. The internal EXPORT_SYMBOL_GPL functions are not exposed to userspace Linux.

This is also a mistake on your part. Linux kernel supports UIO and usermode helpers and so on. To be correct the Linux kernel as part of it feature set includes doing drivers as a closed source user-space program.

You would consider this is a FOSS victory and great, healthy and secure implementation?

FOSS victory that correct its not with a user space binary driver. Healthy that were things get interesting. Being userspace code it possible to use emulations and other things to allow that code to function. Yes containers and other features as well can be used to run old programs.

Secure implementation. Binary driver loaded into monolithic kernel memory space or Binary driver loaded into a Microkernel as userspace program there is no debate on what one is more secure and stable all studies say the userspace program solution is more stable.

There is a catch here the userspace/microkernel driver program driver has overhead so does not perform as well.

Points
1) Linux User mode driver closed source is in alignment with Linux kernel GPLv2 with exception for user-space. Result of doing this you don't end up using patents without a valid license and other things that get parties upset.
2) Linux User mode driver cannot access EXPORT_SYMBOL_GPL functions because those are not exposed to userspace.
3) Linux User mode driver can have containers and Linux security module limitations applied that a kernel mode driver cannot. So from security a Linux userspace closed source driver is more secure than a Linux kernel mode driver if the correct protections around the linux userspace closed source module.

Remember each userspace program has it own memory space. Where everything in kernel space of Linux is really sharing memory space with each other.

So gnattu healthy and secure closed source usermode driver is. Even better closed source usermode driver you are not going to be upsetting parties who have licensed patents to the Linux kernel that you maybe charging money of to use your patents because you are obeying the GPLv2 with exception the Linux kernel has.

Linux kernel mode driver closed source you are walking a tight rope where is really easy todo the wrong thing and use something you don't have the legal right to. That some of the reason why these protections are being added.

[braiam]

That's not what is meant a stable in kernel ABI. A stable ABI is stable across multiple kernel versions

The kernel makes no such guarantee of private/GPL-only functions. The public/non-GPL functions however do have such guarantee. And there has been enough of Linus' spats about breaking it. Hell, the kernel have "broken" them for security in ways that if you aren't doing something malicious, you would not notice (see this https://www.youtube.com/watch?v=Nn-SGblUhi4)