Just find the black guy. If he's for it, then they are opposed and will fight to the death to stop it.

I really hope in the next two years Obama comes out in favor of breathing. Watching Boehner and McConnell repeatedly pass out would be entertaining.

Not quite.

The vote has to be scheduled by the "rules" committee. Which more-or-less means the speaker can prevent any bill from reaching the floor of the House.

Theoretically, the way around this is a discharge petition - if a majority of House members sign the petition, it leaves committee and goes to the floor.

That almost never succeeds, because it requires members of the majority to say "fuck you" to their party leadership, resulting in losing committee assignments and other perks.

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.