Yes, the malware would report back the values for the same image as the non-infected drives, giving you the same results as the majority.

That's how it should be done, but that isn't necessarily how it always will be done. An executive hears that a simple device would let just anyone read their valuable firmware, and suddenly he wants to disable the interface unless you execute a super-secret command. And now your JTAG interface isn't raw hardware access.

Because humans do not write perfect software. In addition, people are willing to aid spy agencies for money.

You boot up with a known good BIOS, after the system has loaded up, while it's still live, you pull the good BIOS chip, insert the bricked one, run your firmware update

And since the malware is already running, it writes itself into the new chip.

Boot from a randomly chosen Linux rescue disk, and check the various proms.

And those proms are read by the firmware in those proms. Why does the firmware have to respond with what is actually running?

With this you can dump what the firmware claims is the buffer and memory of your harddrive.

FTFY.

Simply because attack code doesn't know what output verification code must produce.

Why? To create the malware, they most likely reverse engineered the old firmware. So they know what verification code they must return.

power on, flash your firmware

From what? You saved it to some local storage, where it can be modified. For example, you saved it to your hard disk which you now are attempting to re-flash. But the hard disk was infected. It detects that you ware writing a firmware image to the disk, and injects itself into the new firmware image.

Firmware malware is not a trivial undertaking. So we're talking about extremely extensive effort by people who can develop very sophisticated attacks. You can't expect that they would leave any "easy" way of removing the malware open.

Yeah, it's not like open source software like glibc was recently found to be vulnerable.....

Like if your PC is compromised by an attacker and then you pull the hard drive and [assuming there's a way to get a hash from SMART/ATAPI) you can compare the hash of the firmware that the drive is running to the list of published firmwares at the vendor's site.

Why does the malware have to respond with the actual hash of the firmware? Respond with one of the "known good" hashes.

If you're reading the firmware and calculating a hash, the firmware does not have to give you the firmware that is actually running. Respond with a "known good" firmware image.

Depending on the design of the firmware and the controller chips, even JTAG may not help you - they don't have to actually give you raw access to the device's memory. They're supposed to, but we're not talking about the laws of physics here. The "rules" can be violated.

The vendors may need to move operations outside of five-eyes to remain commercially viable.

Yeah, only five-eyes nations do this kind of thing.

Open-source the whole stack

Won't work. No one is actually looking for esoteric bugs in complex code that can lead to an attack. See: glibc.

Require access to reflash the firmware securely by independent means.

The firmware image on the device does not have to let you reflash it. It can happily report "success!" while doing nothing. It can also re-infect the new image - the device is powered, so the existing firmware can be running. Additionally, you're assuming this "independent reflasher" is itself secure.

Previously I would have thought this a pipedream

Yes, this is entirely a new phenomenon.

Why does the firmware on the drive have to report it's actual hash? The malware could easily respond with a "known good" hash.

You reading the firmware and calculating your own hash? Why does the malware have to respond with the firmware that is actually running? Again, respond with a "known good" firmware image, and go on your merry way.

The problem is the "swap" step. You are either relying on the infected system to actually do the swap, or you need to attach the chip to a separate system to install a known good image.

The latter option is not easily available to most people.

Because persistent storage technology doesn't exist.

You don't have to encounter other species to build bigger and better weapons. Your own species will do, i.e. the entire history of the human species.

A great deal of human advancement came about because of conflict and limited resources caused by our limited land area. We had to conquer each other to get more (whatever you're looking for). Or we only had so much (whatever), so we had to figure out better ways to use (whatever) or replacements for (whatever).

If your species has the ability to travel to anywhere in the galaxy, limited land area is gone. If you want more of (whatever), there's plenty of places to get it. Those places are either uninhabited or populated by people who only have spears, while you have guns. That greatly reduces the pressure to innovate.