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

[oiaohm]

I genuinely find it hard to follow.

Look at his next post. Two sentences, two mistakes.

That normal for someone with C- grade english.

Its good enough to pass university study.<< You would be calling first word there a mistake. "It's" right horrible as it sounds for university course work english "Its" is good enough.

The reality is those two sentences are good enough to be submitted masters thesis with those errors when the subject you are doing is not english.

Lot of people don't go on for UNI study in a lot countries because they don't think they have good enough english. The reality the standard you need for university work is quite low.

Yes you were partly right thinking the way I type looks a little like google translate. Its the near enough is good enough standard of english that universities around the world use it started in the UK in fact those doing google translation used that as a base to how good they had to get the automated translation. There are a lot of punctuation marks that can be skipped without removing meaning.

bug77 I never say I have perfect english. English being my first language does not mean I have to be that great at english. Worse mistake a lot make is you don't need to be great at writing english to be fairly highly qualified. Comprehension of english is a far more important skill include having good comprehension of bad writing.

By the way me writing english for the language without a capital is partly shows my age and country. This is where things get complex.

"Common nouns refer to a general concept or thing and are only capitalized at the beginning of a sentence." There is a arguement that highly valid that english without state of dialects is only a common noun not a proper noun
"Proper nouns refer to a specific person, place, or thing and are always capitalized." English as word covers things like pidgin english and other many other things so is not a specific person, place or thing. So if you are stick strictly to the historic rules of english the world english is only a common noun. This does cause a problem because people think english is a proper noun should be capitalised so they are not writing the dialect my english would be poor Australian English. Yes find yourself a old Australian English dictionary look up the world english notice its lower case for the language and its marked as a common noun not a proper noun. You do need to be careful picking out language faults as some can be the persons nationality/dialect of english.

[bug77]

Uncalled for.

I genuinely find it hard to follow.

Look at his next post. Two sentences, two mistakes.

[vein]

oiaohm Is that Google Translate, or what?

Uncalled for.

[oiaohm]

oiaohm Is that Google Translate, or what?

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

[bug77]

oiaohm Is that Google Translate, or what?

[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.

[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.

[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

[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.

[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.