[sqeaky]

I have no information that conflicts with what you posted but none of that indicates that the CPU gets written to.

Consider that even things like CPU microcode don't get stored on the CPU, it's simply doesn't have persistent storage. CPU microcode is often applied early during OS boots and loaded into memory or CPU cache.

What you have quoted indicates something similar, perhaps the main board or other device with storage of some kind is being written to or perhaps an attacker could write a payload that lived entirely in the bootloader on the main storage.

[mjg59]

Not 100% true - a microcode-based CPU without microcode isn't able to execute anything, so CPUs will ship with an early version of the microcode that's then (as you say) updated during boot.

[sahmeepee]

So I believe this rules out a supply chain attack where someone buys a bunch of CPUs, infects them, repackages them and sells them as new.

If you can't do that, then this feels significantly less problematic.

[mjg59]

They could potentially do that to motherboards, but they could do that anyway (physical access would give you as much access to flash as this vulnerability does). But yes, CPUs should be fine in that respect.

[sqeaky]

But that doesn't persist through reboots, does it?

[mjg59]

Correct, the update has to be applied on every boot, but that doesn't mean there's no microcode in the CPU itself

[sqeaky]

And that information is clearly irrelevant and misleading in this context.

[Vegenoid]

Appreciate the clarification, that makes sense. Maybe we'll get more details on potential persistence methods from the talk they'll give tomorrow: https://info.defcon.org/event/?id=54863