NVIDIA Pushes 62MB Of GSP Binary Firmware Blobs Into Linux-Firmware.Git

[phoronix]

Phoronix: NVIDIA Pushes 62MB Of GSP Binary Firmware Blobs Into Linux-Firmware.Git

As mentioned last week, merged for the Linux 6.7 kernel is NVIDIA GSP firmware support in the Nouveau driver so that these NVIDIA firmware blobs can handle hardware initialization and power management related tasks. This support is optional right now for the GeForce RTX 20 / RTX 30 series hardware with Nouveau but necessary if wanting better performance via re-clocking the GPUs. The GSP firmware is a mandatory requirement for Nouveau with the NVIDIA RTX 40 GPUs and moving forward...

https://www.phoronix.com/news/NVIDIA-Big-GSP-Firmware-Dump

[timofonic]

I call that bloat!

I wonder if some Russian, Pakistani or Chinese hacker would reverse engineer those binary blobs.

[Barley9432]

It's 2023, frankly disagree that 62mb of firmware files is a big deal. You could copy it 16 times before it fills even a 1 GB!

[jeisom]

This good news. The nouveau developers' progress this year has been amazing and hopefully the next piece, NAK, will be ready for testing soon.

[kiffmet]

I wonder if some Russian, Pakistani or Chinese hacker would reverse engineer those binary blobs.

They can't. The blobs are encrypted and the decryption key is in a secure enclave within the GPU. Same goes for AMD GPUs - if the firmware could be decrypted, disassembled/reverse engineered and re-signed(!), people could remove all artificial limitations from their hardware.

AFAIK der8auer has an AMD internal tool that can create signed powerplay tables on Windows, allowing a complete bypass of AMD's clock-, voltage- and ppt- restrictions at least on RDNA2. Ahh, I wish that it was leaked.

[You-]

It's 2023, frankly disagree that 62mb of firmware files is a big deal. You could copy it 16 times before it fills even a 1 GB!

The EFI partition is normally pretty small, often smaller than 1GB.

Also as posted elsewhere, the 535.01 firmware files do not have binary compatible interfaces with the 535.02, 535.03 etc files, so for each driver series you could easily end up with 10 lots of the firmware files.

Those are the patch series. Then there are the minor release series.

Since last 31 May last year, there have been 65 releases. 65 x 62mb = over 4GB of firmware. Note the Super series of hardware hasnt been released yet, so this will likely get larger very soon.

[qarium]

The EFI partition is normally pretty small, often smaller than 1GB.
Also as posted elsewhere, the 535.01 firmware files do not have binary compatible interfaces with the 535.02, 535.03 etc files, so for each driver series you could easily end up with 10 lots of the firmware files.
Those are the patch series. Then there are the minor release series.
Since last 31 May last year, there have been 65 releases. 65 x 62mb = over 4GB of firmware. Note the Super series of hardware hasnt been released yet, so this will likely get larger very soon.

yes this is really insanity. why do all the people think this is a good idea ?

[stormcrow]

It's 2023, frankly disagree that 62mb of firmware files is a big deal. You could copy it 16 times before it fills even a 1 GB!

I agree. The problem with 62 MB with a modern desktop or server computer and a modern network is there are historical limits on how large the kernel & initramfs images can be and still load, not with storage or raw CPU power to decompress. Even a 15 year old desktop CPU can decompress a 100 MB gzip file in just a couple of seconds (no anemic embedded system is going to have these GPUs ). It's more of a problem with the kitchen sink approach most distributions need to use in generic kernels than it is with a more customized boot. Eventually this is going to lead towards a more customized boot stack chosen at install time, and revisited as needed (Ubuntu derivatives do something similar to this already with Nvidia driver support): Which GPU(s) do you use? (A) Intel only, (B) AMD dGPU or APU, (C) Nvidia Optima, (D) Nvidia only.

[stormcrow]

The EFI partition is normally pretty small, often smaller than 1GB.

Also as posted elsewhere, the 535.01 firmware files do not have binary compatible interfaces with the 535.02, 535.03 etc files, so for each driver series you could easily end up with 10 lots of the firmware files.

Those are the patch series. Then there are the minor release series.

Since last 31 May last year, there have been 65 releases. 65 x 62mb = over 4GB of firmware. Note the Super series of hardware hasnt been released yet, so this will likely get larger very soon.

Which is why it's never been a good idea to use the EFI partition for anything more than a boot stub (some Linux distros being the only OSes stupid enough to do so that I'm aware of). The distributions that use it for the entire boot chain are just asking for trouble - and will eventually find it for various reasons: some technical like the lack of any kind of internal data integrity in FAT nor permissions and security features - you can't count on motherboards to support more than the base requirement FS support (meaning no more than FAT), some because they didn't think the decision through in just how big the boot chain may grow in the future. It's not feasible for users to have to try to figure out how to resize or move their EFI partition because a year or two after install the boot chain grew way more than anticipated.

[User42]

Which is why it's never been a good idea to use the EFI partition for anything more than a boot stub (some Linux distros being the only OSes stupid enough to do so that I'm aware of).

Oh... I'm not sure you're aware of what Linux and other OSes put in there. Are distros putting too much in there? Most of them, yes. Is a boot stub sufficient? Well, how are you supposed to pivot root (or get the new root) if you have no access to pci, sata and usb controllers; if you don't have access to the network and if you can't mount any filesystem?

Do you need gpu code in there? Probably not. And luckily most distros don't do that... Windows and Mac have to manage the same hardware so they need the same amount of kernel, driver and init system as Linux. Linux has taken the easy/good-enough/maintenable/customizable initramfs approach, other OSes have taken different routes but in essence most of what is in efi serve the same purpose.