3 ms·
Can someone explain how the persistence can work as described here? I thought the CPU microcode was stored in the BIOS, and the CPU itself doesn’t have a persis
by echoangle 2y ago
Can someone explain how the persistence can work as described here? I thought the CPU microcode was stored in the BIOS, and the CPU itself doesn’t have a persistent memory. Wouldn’t I have to exchange the Motherboard and not the CPU if I was infected by this? Or just reflash the BIOS, assuming the corrupted BIOS doesn’t somehow prevent BIOS flashing?
Edit after looking it up (leaving this comment in case someone else has the same question): Apparently microcode is in fact stored in the CPU itself and it does have permanent storage. The BIOS is only used for updating this internal memory and doesn’t transfer the microcode on every boot. I still wonder if the microcode patches are somehow validated/signed though, otherwise everyone with a kernel exploit could issue update commands to the BIOS with malicious microcode content?
- trebligdivad 2y agoYes, probably - but don't forget that the normal user way of 'reflashing the BIOS' is to tell the BIOS to reflash a new image; so in theory (but hard) a malicious BIOS could keep itself in there. If you used JTAG etc to reflash the BIOS externally then yes you could probably clear it out.
- telgareith 2y agoSome (most?) motherboards now have a way to reflash a bios in "no POST" scenarios. There's either a dedicated microcontroller or it reuses the embedded controller to read a BIOS image from a USB mass storage device. It works even when there's no CPU installed.
- mjg59 2y agoThe microcode store in the CPU itself shouldn't be writable (if it were we wouldn't need to load microcode updates from the firmware or the OS on every boot), but there needs to be some microcode on there for the CPU to be able to execute the firmware code that updates the microcode. And yes, microcode is signed (and typically also encrypted). SMM shouldn't have any special level of access to the microcode, any persistence here is likely via the system firmware (which should, as a result, be caught by Platform Secure Boot on platforms where that's enabled)