That's a bit of a tired and somewhat misleading argument.
Take a look into the kernel-firmware repo, and you will see a tremendous amount of binary firmware blobs. For example the Intel micro-code blobs are protected by ~7 layers deep of encryption, wifi drivers may have government regulatory issues with sharing firmwares in anything but binary form. So let's please drop the evil binary blob nonesense...
The kernel does in fact accept small or large binary blobs, and some of them even come with source code...So I guess the key takeaway is to look at what separate the Nvidia driver/firmware from all those other binary firmware loading drivers.
Hint, it has more to do with hiding the program interface, and using abstractions within abstractions.
This small tirade of yours is arguing against a strawman.
GP is likely referring to the userspace component of nvidia's driver, not the actual blob that gets loaded onto the gpu. If it is indeed true that you need to run proprietary userland code, then this open-source release is nothing but a way to circumvent the GPL issues that lead to nvidia's driver partially breaking in Linux 5.??.
While not ideal, I like many don't have a hard stance against loading proprietary hardware firmware blobs. I, however, absolutely take issue with running opaque user-space programs.
All closed-source kernel modules and a part of the firmware blobs (those that are for devices which have communication interfaces, especially wireless interfaces, and which may access directly the memory space without being blocked by a MMU under the control of the OS kernel) are major security risks, because they might be controlled by an attacker, with no means of detection by the user.
With a security-strengthened operating system, or with a VM/container/sandbox, it is possible to ensure that any opaque user-space program is no security risk.
I prefer very much open-source user-space programs for 2 reasons:
1. I am only seldom content with a program conceived by someone else, because usually I want to do something else than they had in mind and their program is suboptimal for my use case. When the program is open-source, that does not matter. I can modify it and combine it with other programs, to do whatever I like.
2. Whenever there are problems due to bugs, incomplete documentation or misconfigurations, if the program is open source any problem can be solved sooner or later, usually sooner. With proprietary programs, typically one gets only some incomprehensible error messages and it may happen that entire departments of IT professionals try for weeks to solve the problem, without any progress. (I had such a case last year; after upgrading an old company laptop with a new one, MS Teams stopped working; 4 or 5 IT support people distributed over 3 continents attempted to discover the cause over 2 weeks, but they all failed).
These 2 reasons make the open source programs much more desirable, but if you have to also use some opaque user-space programs for specific tasks, e.g. a Synopsys Verilog/VHDL synthesis program for designing with a FPGA, that is no big deal.
On the other hand, using an opaque kernel module which may contain either an intentional back-door or just an unintentional bug which may cause your computer to freeze exactly before saving some large piece of work, or which may corrupt you file buffers before being saved, this is much worse than the use of any opaque user-mode program.
> With a security-strengthened operating system, or with a VM/container/sandbox, it is possible to ensure that any opaque user-space program is no security risk.
This is absolutely not true.
It is possible to restrict an opaque user-space program to the minimal set of permissions it requires.
In this particular case, the program needs to manipulate system hardware in undocumented ways, via vendor code which is extending the kernel.
> With a security-strengthened operating system, or with a VM/container/sandbox, it is possible to ensure that any opaque user-space program is no security risk.
In theory this may be true. But the particular opaque user-space program is talking to a driver authored by the same team. That driver is talking to hardware that has access to all of the memory in your computer.
The odds are high that a userspace program talking to this kind of driver could make your computer do something you don't want it to do in a way that is very difficult to suss out just by reviewing the driver source code.
(I agree that an open driver is a great improvement over a closed one. But I don't think you can make any strong guarantees about the safety of the closed userspace portions of this one, yet.)
I'm not sure why you were downvoted; this is 100% correct. Open source makes adding backdoors much more difficult, but I imagine GPU driver code is so complex that there are likely security flaws that even the entire open source community wouldn't catch. Yes, an open source driver is an improvement in many ways, but it certainly doesn't solve these problems because the attack surface is so gigantic.
I don't think, for accelerating a desktop graphics card used across your entire desktop environment, IOMMU changes my argument at all.
I believe it *does* help if, say your desktop's integrated video works natively and you have a second card you want to pass through to a gaming VM. Or if you have a server with no card shared between users and a one-card-per-user scenario.
My view is that nvidia's hardware can work however they want it to. FOSS firmware would be cool in the same way that FOSS hardware would be cool, but it's not something I expect. I also don't care that much whether the proprietary firmware is stored on on-board flash and programmed from the factory or if it's uploaded by my OS when the driver is loaded.
But I would prefer if the code I run in userspace or kernelspace is FOSS.
> I also don't care that much whether the proprietary firmware is stored on on-board flash and programmed from the factory or if it's uploaded by my OS when the driver is loaded.
Bingo!
Nobody cares about firmware, that's not the issue, never was... but somehow that became the narrative repeated by people who don't know what they are talking about.
Many firmware loading drivers have caused drama over the years. I'm not sure if anybody remembers when Pottering and Sievers re-worked udev to change the ordering of how firmware was loaded from user-space, trying to improve how computers booted, by graphing firmware loads, determining the loading ordering, etc... which sometimes need to happen before it's kernel driver loads, or sometimes the driver itself is able to load the firmware, or the driver begin lazy, expects udev to load the firmware after the kmod is loaded... As a result, the kernel loads firmwares itself.
I'd say the whole firmware thing needs to be put under review, with concrete rules how they are loaded, and what their interfaces has to look like, and what hardware abstraction rules actually apply.
I think this firmwareblob vs. kernelblob vs. userspace blob needs to be decided on a case by case basis, and no strict line that shall not be crossed can be drawn anywhere. The important factor is, does their contribution help the community or not, will it allow the community to fix bugs and port stuff to a new innovative kernel, without it needing to re-implement everything from Linux?
Personally I would try to decide on blob size and scope. With nvidias driver I suspect that require massive firmware and userspace blobs, and the kernel driver is probably just a pass-through API. I would argue that this doesn't really move the community forward.
However if the blobs are small and simple, and have specific scope and a reason, like legislation or security, maybe even calibration data blobs, are useful independent of the OS itself, then I would give them a pass, since it allows the community to build upon.
> this open-source release is nothing but a way to circumvent the GPL issues
Talking about strawman arguments... that's a doozie!
Instead of ignoring your strawman, staying focused on the topic...I'm going to address this nonesense...
Firstly Nvidia is not in violation of the GPL. Secondly, nobody cares about GPL violations, most certainly not the mainline kernel community. They do not pursue blatant GPL violations, because litigation is not productive in terms of improving the kernel, but keep in mind Nvidia is not violating the GPL. Thirdly, user space libraries that interface with a kernel API are not violating the GPL. Folks are allowed to run proprietary software on Linux. Do I like that, no... I certainly don't love it. However, Nvidia running user space graphics libraries is not much different than Radeon drivers using Mesa in userspace, it's how graphics architectures work in 2022.
So it's kidna ironic you're arguing about something separate (straw-man), and even then that argument fails...
Now then, putting your tangent aside...
The whole point here is to start with the kernel, and get the kernel wrapper driver that interfaces with the hardware's firmware binary interface open sourced. The whole point is to get the driver into mainline, someday... Once we have that, we can untangle the the spaghetti of graphics API libraries, perhaps even port them to Mesa. Nvidia most certainly uses an intermediary low-level graphics representation for their graphics cards, so they can support all the various graphics APi's, or what not... it's a very common pattern for graphics cards... one Radeon even fell into not long ago. So it's just a matter of time before we decode this stuff.
But you're not wrong in terms of Nvidia's overall stack being proprietary, at least for now. But that's not important, what's important is Nvidia users wont' have so much drama when their distro kernel upgrades, and they screen goes blank thanks to Nvidia's driver not being compatible with the changed kernel ABI, and the AKMOD not being able to handle it.
The carl firmware at https://github.com/chunkeey/carl9170fw should put that argument to rest. That is Wifi firmware source code for the Wifi I currently use.
Easily changed likely means there's a physical knob somewhere that you could accidentially poke as a layperson.
Not that you get a three year CS education, figure out how your distribution packages dependencies, install the correct embedded toolchain (good luck), find out exactly which chip is in your device, fetch the proper firmware source code in the right version, build the thing, figure out how to flash the result onto the chip / read the Linux kernel sources to figure out the filename inside /lib/firmware. That's not easy.
Please note that the Debian firmware-linux-free package does not build carl9170fw from source. There is proper packaging (source package called carl9170fw, binary package will be firmware-carl9170) being worked on but it isn't completed yet:
Take a look into the kernel-firmware repo, and you will see a tremendous amount of binary firmware blobs. For example the Intel micro-code blobs are protected by ~7 layers deep of encryption, wifi drivers may have government regulatory issues with sharing firmwares in anything but binary form. So let's please drop the evil binary blob nonesense...
The kernel does in fact accept small or large binary blobs, and some of them even come with source code...So I guess the key takeaway is to look at what separate the Nvidia driver/firmware from all those other binary firmware loading drivers.
Hint, it has more to do with hiding the program interface, and using abstractions within abstractions.