Inlined proprietary binary blobs in code files

[throwaway1037]

NVIDIA Open GPU Kernel Modules Version

Affects all versions

Does this happen with the proprietary driver (of the same version) as well?

I cannot test this

Operating System and Version

Affects all OSs

Kernel Release

Affects all kernels

Hardware: GPU

Affects all GPUs

Describe the bug

Many supposedly "open" source files contain inlined proprietary binary blobs in the form of long hex arrays.

Eg.

• https://github.com/NVIDIA/open-gpu-kernel-modules/blob/main/src/nvidia/generated/g_bindata_kgspGetBinArchiveBooterLoadUcode_GA100.c
• https://github.com/NVIDIA/open-gpu-kernel-modules/blob/main/src/nvidia/generated/g_bindata_kgspGetBinArchiveBooterLoadUcode_GA102.c
• https://github.com/NVIDIA/open-gpu-kernel-modules/blob/main/src/nvidia/generated/g_bindata_kgspGetBinArchiveBooterLoadUcode_TU102.c

As discussed in #35, which has been left to languish, the best option is to release the source code to all blobs on which these modules depend under free software licenses.
Unlike #35, these blobs are not external to this repo and are inlined in code files themselves.

To Reproduce

See above.

Bug Incidence

Always

nvidia-bug-report.log.gz

This log is not needed.

More Info

I don't suppose this counts as a "functional bug" per se, but the lack of freedom is an issue and is a bug.
There was no option for a "non-functional" bug.

[mtijanic]

These are small microcodes which are only used to load gsp.bin to the target risc-v core. They are loaded separately from the main gsp.bin payload, so it makes no sense to merge them into one file and then extract at runtime.

They could be stored as individual firmware files on disk, but it wouldn't make much difference. The "bindata" infrastructure to embed microcodes into the driver is something that we are using on all platforms, so there's nothing to be gained by complicating the code further.

An upstream linux-only driver will also require these microcodes and there it would make more sense to keep them as separate firmware files. See also #62 (comment)

I'm going to close this as it's just a quirk of this driver's architecture.

[throwaway1037]

@mtijanic you missed the whole point of the bug.
The issue is not just that they're inlined, the issue is that they're proprietary.
See also my comment on #62.

[mtijanic]

Well, that same complaint applies to gsp.bin itself, which makes this a duplicate of #35. As explained there, there are no plans to change this.

[throwaway1037]

@mtijanic, it's not a duplicate because this bug is about the inline proprietary microcode, not gsp.bin.

If these microcodes are not liberated by releasing the source code under a libre license, then many distros will have to remove them, which is a logistical nightmare that Linux-libre has been dealing with for years.

[throwaway1037]

@mtijanic I should also add that labelling these modules as "open" is a lie, because they contain inlined proprietary microcode.

[PAR2020]

@throwaway1037, you have made your point, several times as you mention. We have acknowledged your request and your frustration, advised this is a long new journey for us that has just begun. Continuing to "beat the dead horse" only will frustrate you, and us, with no good to come of it.
We are actively working the distribution question of the binaries. Let's get through that first.

If we might consider open sourcing the firmware as a feature request, you could open a discussion for that, and have the community vote on it. That of course doesn't guarantee adoption, but it would give community interest ammunition to nudge NVIDIA along that path - if they were to consider it at a later date. Fair enough?

[throwaway1037]

@PAR2020, if moving this conversation to a discussion and voting can kickstart the liberation of the firmware and microcodes, I'm on board. :)

[PAR2020]

OK I'll move it to a discussion - as I said, there is no guarantee on adoption, but a solid voting gauge will take us to the next steps. Thanks for you understanding and cooperation!