4 ms·

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

by sqeaky 2y ago

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.

Vegenoid 2y ago
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 https://info.defcon.org/event/?id=54863
mjg59 2y ago
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.
- sqeaky 2y ago
  But that doesn't persist through reboots, does it?
  - mjg59 2y ago
    Correct, the update has to be applied on every boot, but that doesn't mean there's no microcode in the CPU itself
    - sqeaky 2y ago
      And that information is clearly irrelevant and misleading in this context.
- sahmeepee 2y ago
  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 2y ago
    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.