Radeon/AMDGPU Firmware Binary Blobs Updated, Polaris Added

[chithanh]

However, I understand that this would reveal things that manufacturers would prefer remain secret, as they would simplify cloning by 3rd parties

I think this is not even the main motivation for keeping things secret.

Having stuff open might allow users to break DRM schemes more easily. Companies hate it if you break their DRM, because of contracts with the content industry.

Secondly, having code open makes it easier for patent aggressors to spot potential infringement.

So in order to keep attack surface small, companies prefer to keep stuff closed.

That being said, do AMD GPUs work at least in VESA mode without acceleration if the firmware is not loaded by the driver?

It is possible, but the kernel does not handle that situation gracefully at present.

Also, the firmware files don't seem that big, would it be possible to put them into a EEPROM (or even a ROM, no need to modify it) so they can act as a fallback should the required firmware not be available?

That is also possible, but it costs money. According to bridgman, the OEMs do not expect an increase business that would allow them to recover these costs.

[Amarildo]

If you mean "so much for open source hardware" (the "blobs" discussed here are HW microcode which we run from on-chip RAM rather than on-chip ROM) that is true -- we never talked about opening up hardware designs. If you mean "so much for open source drivers" the drivers have been open source from the start.

We have tried a few times to get board vendors interested in loading the microcode images in BIOS code rather than in the driver, but haven't had much interest since (a) it drives up board cost and makes microcode updates more difficult, (b) it's very difficult to quantify the market for those boards.

Even though I'm a "GNU-head", I allow the firmware to run. AMD's firmware is the only proprietary piece of code that I allow to run on my hardware, because it's a video card firmware that doesn't run on the host OS or CPU.

However, I will never allow network card firmware to run You can't trust those.

[Vyrlokar]

I think this is not even the main motivation for keeping things secret.

Having stuff open might allow users to break DRM schemes more easily. Companies hate it if you break their DRM, because of contracts with the content industry.

and decoupling the DRM from the rest of the blob can be a lot of work if it's architected that way from the start, so you can't have open everything but an optional blob for DRM...

Secondly, having code open makes it easier for patent aggressors to spot potential infringement.

So in order to keep attack surface small, companies prefer to keep stuff closed.

Ugh, software patents. AFAIK, nothing good came out of a software patent. (Not extending this to the rest of the patent field because I lack enough knowledge of it, and people would be quick to point me to at least one exception rendering my whole point false, but I also feel the same about patents in general).

It is possible, but the kernel does not handle that situation gracefully at present.

Well, this part is fixable, though I wonder if it's worth fixing. After all, if the driver is not present, the card falls back to VESA mode anyway, right? so the actual use case is only for those with the driver and without the firmware, and that's a borked install anyway, right?

That is also possible, but it costs money. According to bridgman, the OEMs do not expect an increase business that would allow them to recover these costs.

I imagine that the problem is less about the ROM (that can be had for penies, probably, given that it probably only needs to be a few MBs) and more about the extra logic and PCB complexity to handle the fallback. Of course, AMD could make it easier for OEMs if they included the rom and the fallback logic in the GPU chip, because then OEMs would not need to do anything. Remember, we're talking about fallbacks for when the firmware can't be loaded/isn't beeing loaded from disk. It does not need to be updatable, since it can assume that if the driver isn't loading the firmware correctly, it's because there's a problem with the driver.

In fact, it should be useful only for when there's a borked install that doesn't load/corrupts the firmware files, and for Open Source supporters that don't want any non-free binary blobs in their HDs.

[Amarildo]

When you are using cpu from amd or intel, you will use firmware that spies you.

Any evidence for that?

[Amarildo]

You have no evidence that users can not trust rtl8168g-2.fw and irony is hard to understand.

No, I made no claim. You claimed that users are being spied, so the burden of proof is yours, not mine.

[Amarildo]

Exactly what I just said. I made no claim that users can [edited]or cannot[/edited] trust other firmware. The only thing I said is that I personally allow the GPU firmware because it only runs on the device.

[Amarildo]

Indeed, I made a little mistake. Already edited.

[Amarildo]

Smiley or not, You can not trust firmware.

We cannot trust PROPRIETARY firmware. FOSS Firmware can be trusted.

[chithanh]

Being open source is a prerequisite to trusting software, but by itself is not sufficient.

https://www.schneier.com/crypto-gram/archives/1999/0915.html#OpenSourceandSecurity

It is correct however that closed source software (including closed source firmware) cannot be trusted. So the system running that must be designed that it is still secure when assuming the worst about the firmware.

[bridgman]

What happened to that head-scratching emoticon ?