NVIDIA Windows/Linux Graphics Drivers Hit By A Series Of Security Vulnerabilities

[Alexmitter]

Lesson learned: you keep the same driver for all platforms, you fix bugs on all platforms in one go

One word for those who think open source is a fix for this: OpenSSL.
Open source helps, but it's not a foolproof solution. Also, Nvidia seems to have fixed these rather quickly, looking at some of the CVEs, it looks like they are all two months old today.

Not Open Source is the fix, free software is the fix. Companies do not invest time in software that helps their competition but does not guarantee it will also help them back. That promise is worth a lot to companies, and most of work happily together on things that benefits their arch nemesis as long as they know that they will get the same improvements.

That is why OpenSSL is notoriously less reviewed then lets say the Linux kernel for example

[marios]

Lesson learned: you keep the same driver for all platforms, you fix bugs on all platforms in one go

Sharing common code for platforms is ok. What nvidia does is not.
Different platforms have different interfaces, and some things do not match. For kernel modules, the common code is not expected to be that large, especially if you do most of your stuff in user space libraries. Which means large part of the bugs is expected to be in the OS specific code.
I have not read nvidias code (I might have died laughing if I had), but based on some data I think that the linux (and bsd most likely) nvidia driver is just a bad port of the windows driver for linux. The data that I have is the terrible performance of nvidia for linux compared to windows (just take a look at basemark vulkan results if you dont believe me). Also the fact that most bugs affect all platforms is a red flag.

[Volta]

I agree with the sentiment that drivers should be open. But, this seems to be speculative unless you actually know what validation happened (to closed source drivers).

That is actually probably a bigger issue, you cannot be certain the rigor of validation or review in many cases.

I compared them to AMD Open Source drivers which probably have lower CVE record (I didn't check, but I don't remember Phoronix mentioning a single CVE in AMD drivers) and this was the main reference.

[bug77]

Sharing common code for platforms is ok. What nvidia does is not.
Different platforms have different interfaces, and some things do not match. For kernel modules, the common code is not expected to be that large, especially if you do most of your stuff in user space libraries. Which means large part of the bugs is expected to be in the OS specific code.
I have not read nvidias code (I might have died laughing if I had), but based on some data I think that the linux (and bsd most likely) nvidia driver is just a bad port of the windows driver for linux. The data that I have is the terrible performance of nvidia for linux compared to windows (just take a look at basemark vulkan results if you dont believe me). Also the fact that most bugs affect all platforms is a red flag.

Yeah well, interfaces are just that: interfaces. The real meat of the driver is elsewhere (as proven by these bugs and their fixes).
And I am fully aware of the downside: while share code means one fix solves everything, messing up in one place will affect everything
But in the software world, shared code is always considered the better approach regardless.

[bug77]

I compared them to AMD Open Source drivers which probably have lower CVE record (I didn't check, but I don't remember Phoronix mentioning a single CVE in AMD drivers) and this was the main reference.

They're there, don't worry about it

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-19082

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-19083

[piotrj3]

I compared them to AMD Open Source drivers which probably have lower CVE record (I didn't check, but I don't remember Phoronix mentioning a single CVE in AMD drivers) and this was the main reference.

Invalid to compare, as all security researching for Windows counts in Nvidia case for Linux and vice versa, for AMD GPU open driver only direct security researching counts. It is like people complain about Adobe Reader security, while in reality when good security researcher tries to find something on them, they have hard time finding something, while such PDF viewers on linux (at least used to) are swiss cheese. The reason is simple - security researchers focus on popular products in default configuration. AMD GPUs are like 3-4 times less popular then Nvidia, and then you have that crazy windows vs linux ratio of users, and on top of that on Linux you have diffrent branches of drivers for AMD. Simply chance some security researcher does look at Nvidia and finds a bug that affects linux is way way way higher then AMD open source linux driver.

What in reality you should consider important is:
- are there cases of zero days exploited in the wild,
- if you used fuzzers for let's say 2 months in row from user mode, how many kernel crashes do you get for 2 different products. I would generally say it is pretty good measurement since they are so called "low hanging fruits" that are easy to catch.

[oiaohm]

The bad point here is the fault Nvidia has really just CVEs was talked about in 2013 for the open source driver http://phd.mupuf.org/files/fosdem2013_drinext_drm2.pdf . Its why DRI2 was using GEM handles and DRI3 is using DMA BUF to pass between processes.

To be correct the CVE of nvidia that match the 2013 fix up in open source drivers just for the GPU part is:
CVE‑2021‑1052 NVIDIA GPU Display Driver for Windows and Linux contains a vulnerability in the kernel mode layer (nvlddmkm.sys) handler for DxgkDdiEscape or IOCTL in which user-mode clients can access legacy privileged APIs, which may lead to denial of service, escalation of privileges, and information disclosure.
CVE‑2021‑1053 NVIDIA GPU Display Driver for Windows and Linux contains a vulnerability in the kernel mode layer (nvlddmkm.sys) handler for DxgkDdiEscape or IOCTL in which improper validation of a user pointer may lead to denial of service.
CVE‑2021‑1056 NVIDIA GPU Display Driver for Linux contains a vulnerability in the kernel mode layer (nvidia.ko) in which it does not completely honor operating system file system permissions to provide GPU device-level isolation, which may lead to denial of service or information disclosure.

Yes those two IOCTL classes faults existed in open source graphics drivers in 2013 we are 7 years later here they don't exist any more in open source drivers.

The 2021-1056 in fact documents a incorrect way to fix this problem properly. First question why was the driver needing to honor the operating system file system permissions that says Nvidia is doing something like GEM Handles. There is no need to be honor file system permissions in the driver if what you were using was files under Linux in the first place so letting the OS process the security. DMA BUF has a stack of existing security stuff. Windows has its own equal to dma buf for graphical. Yes this would mean truly having to write per platform GPU memory management as Windows and Linux/FreeBSD have different security models and need different code in memory management so the OS security is processed on it out side the driver. There is a catch for Nvidia they do this they will have slightly slower performance.

Yes Nvidia with eglstreams has argue for graphical buffers shared between processes outside the operating systems security model.

The reality here under Linux the design of GBM being per process and using DMA BUF to transfer between processes is security right. Nvidia if they don't like GBM need to provide something per process equal. DMA BUF has to exist to PRIME usage so reusing its security parts for application to application reduced down the amount of security code that has to be maintained. Yes windows buffer sharing for there version of PRIME also has a nice set of security parts provided by the OS around it. This is a case Nvidia has been reinventing the wheel inside their driver and in the process made a square wheel that attempting to run on a flat road. Yes this reinventing the wheel all starts with the foolish idea that we will share as much code as possible between platforms instead of coding what needs to be platform unique for security. Yes how security is processed is platform unique like it or not. yes this platform unique goes up to memory management on cpu and gpu.

[bug77]

oiaohm Is that Google Translate, or what?

[oiaohm]

oiaohm Is that Google Translate, or what?

That my native english writing style. Its good enough to pass university study.

[vein]

oiaohm Is that Google Translate, or what?

Uncalled for.