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.

Depends on how the gravity control works. It may not be possible to have fine enough control to use it as a weapon, especially without having developed advanced sensors and control systems.

Imagine the gravity control is done with a magical rock. If the alien touches it, the rock is able to "lock on" to large masses like planets or larger. The rock is able to create a wormhole to such a large mass, allowing passage.

How do you weaponize it? Your interface is primitive and imprecise - you're just touching a rock. You don't have sufficient control over the effects of the rock to turn it into a weapon.

Yes, using the BIOS to flash the BIOS will definately remove any malware.

Oh wait.....

And my use of those "PKI and X.509 type certificates" is to call a library to deal with them, blithely ignorant as to what those libraries are doing with the keys. Just like I don't write my own code to implement HTTP, and then TCP, and then IP and then ethernet.

The other enormous stupidity in this question is PKI is only one solution, and may not be the best one. Encrypted zip may work just fine, with a password transmitted via another pathway. Or if the document is in a format that supports encryption, hence the question about PDF. Or scp/VPN/etc to a secured share. Or print it out and put a stamp on it.