Nouveau Gallium3D Moves Closer Towards OpenGL 4.5 Compliance

[anth]

About those Nvidia firmware, is not possible to extract them from the closed source driver, or is there a legal shenanigan prohibiting doing it?

That used to be possible, but as of the 900 series Nvidia require encryption which prevents that.

[smitty3268]

That used to be possible, but as of the 900 series Nvidia require encryption which prevents that.

Can't they just copy the encrypted firmware out of the binary drivers though? Or is there something stopping that? License, I guess? They definitely can't do the reverse-engineered stuff they used to do.

[starshipeleven]

Can't they just copy the encrypted firmware out of the binary drivers though?

They have been extracting firmwares from NVIDIA blobs for a long time by doing the same trick NVIDIA does to avoid GPL issues (i.e. have a script do the leg work in the user PC) https://nouveau.freedesktop.org/wiki/VideoAcceleration/

They can't do that this time as they need to load a signed firmware, and afaik the blobs they can extract from the driver are not signed.

[Atirage21]

What does it look like with prepraring of DEINTERLACE_TEMPORAL_SPATIAL ?

[smitty3268]

They have been extracting firmwares from NVIDIA blobs for a long time by doing the same trick NVIDIA does to avoid GPL issues (i.e. have a script do the leg work in the user PC) https://nouveau.freedesktop.org/wiki/VideoAcceleration/

They can't do that this time as they need to load a signed firmware, and afaik the blobs they can extract from the driver are not signed.

I guess my question is why they can't just record the blob that the proprietary driver sends to the hardware which is presumably signed at that point, rather than trying to dig it directly out of the binary.

[starshipeleven]

I guess my question is why they can't just record the blob that the proprietary driver sends to the hardware which is presumably signed at that point, rather than trying to dig it directly out of the binary.

Because it's either already encrypted when travelling between the driver and the hardware, or because NVIDIA can easily do that in the next generation of GPUs if they just extract firmware now.

Really, they can't win this fight through brute force.

[smitty3268]

Because it's either already encrypted when travelling between the driver and the hardware

But that's my point. It seems like they should be able to copy the encrypted firmware - it's not like they need to decrypt it, that's what the hardware does.

I'm clearly missing something, just not sure why it's not that simple.

[starshipeleven]

But that's my point. It seems like they should be able to copy the encrypted firmware - it's not like they need to decrypt it, that's what the hardware does.

I'm clearly missing something, just not sure why it's not that simple.

That's a long-solved problem by public key crypto. The hardware has its own key (each GPU has its own), the blob has its public key, and they salt it with something time-dependent so that it's not the same all the time, then do a Diffie-hellman key exchange to create the encryption key they will then use to encrypt the firmware.

Since the "salt" they are using is time-dependant, the encryption key used for the transfer will be different each time, so whatever you intercept is useless.

And note that "time-dependant" does not mean that it is using the system clock, it can use whatever it wants just to count time somehow, be it some loops in the code, or whatever.
The GPU can count the noise on its voltage rails or something, like the chaos key (true hardware RNG) does.
Only one of the two should salt its own the key, if both salt it then it's reading garbage.

Really it's not terribly hard to lock everything down.

[smitty3268]

That's a long-solved problem by public key crypto. The hardware has its own key (each GPU has its own), the blob has its public key, and they salt it with something time-dependent so that it's not the same all the time, then do a Diffie-hellman key exchange to create the encryption key they will then use to encrypt the firmware.

Since the "salt" they are using is time-dependant, the encryption key used for the transfer will be different each time, so whatever you intercept is useless.

Ahh, I knew that was a thing for websites and such but didn't realize they'd go to so much trouble within the hardware and driver directly. I suppose it makes sense though.

[zwhconst]

That's a long-solved problem by public key crypto. The hardware has its own key (each GPU has its own), the blob has its public key, and they salt it with something time-dependent so that it's not the same all the time, then do a Diffie-hellman key exchange to create the encryption key they will then use to encrypt the firmware.

Since the "salt" they are using is time-dependant, the encryption key used for the transfer will be different each time, so whatever you intercept is useless.

And note that "time-dependant" does not mean that it is using the system clock, it can use whatever it wants just to count time somehow, be it some loops in the code, or whatever.
The GPU can count the noise on its voltage rails or something, like the chaos key (true hardware RNG) does.
Only one of the two should salt its own the key, if both salt it then it's reading garbage.

Really it's not terribly hard to lock everything down.

Sorry if this post is abrupt.

I'm not a crypto expert but I think, in general, MITM attack is feasible as long as we can control one end of the two communicating ends (just like malicious root certificate injection to a web browser). And the binary driver should be considered under our control if we reverse engineered enough bits of it. Isn't that right?

Or could you be more kind to describe the communication process in more detail?