Reverse Engineering x86 Processor Microcode [pdf](usenix.org)
usenix.org
Reverse Engineering x86 Processor Microcode [pdf]
https://www.usenix.org/system/files/conference/usenixsecurity17/sec17-koppe.pdf
9 comments
The significance of this achievement is that microcode and its update mechanism has been historically undocumented and hidden from public scrutiny by processor vendors (AMD and Intel in this case), while at the same time the lowest level of abstraction in a computing platform and thus extremely powerful. However it is not unreasonable to consider that well funded state actors have developed microcode exploit technology that would make their control over a system undetectable and impossible to remove. The recent leaks have shown exploits that target hard drive firmware for example.
Microcode updates have to be rerun every boot since the updates aren't stored. Modern chips use only signed updates.
I'd be pretty surprised if they were successfully attacking chips through this mechanism. There are so many other devices that are much easier to own.
I'd be pretty surprised if they were successfully attacking chips through this mechanism. There are so many other devices that are much easier to own.
I'd be pretty surprised if US govt have never send gag order to Intel and AMD.
This is really amazing work. Physically removing layers of the chip to get images of the microcode ROM, inferring stuff from patents, writing their own OS for full control over the chip... wow.
I wonder how much % of my CPU potential performance is given to all this "gimping" done in order to provide state actors a backdoor to every PC and to help the CPU manufacturer recover field servicing costs.
There is a diagram of part of the chip with the microcode engine highlighted. It is about the size of an integer ALU port, it looks like. Much, MUCH smaller than L2 cache.
Ben Hawkes' analysis of the update mechanism comes to mind, unclear why the authors did not mention it.
inertiawar.com/microcode/hawkes_intel_microcode.pdf
inertiawar.com/microcode/hawkes_intel_microcode.pdf
That's a very different sort of analysis. Ben Hawkes analyzed the cryptographic structure of the update blob on Intel CPUs but didn't analyze the payload because he couldn't decrypt it. The article here reverse engineered the payload on CPUs where it's not encrypted in the first place.
Agreed. Note that the update mechanism in itself involves microcode to operate on the blob.