Hi all,
I think some of you might already noticed a nice paper:
Microcode is an abstraction layer on top of the physical components of a CPU and present in most generalpurpose CPUs today. In addition to facilitate complex and vast instruction sets, it also provides an update mechanism that allows CPUs to be patched in-place without requiring any special hardware. While it is well-known that CPUs are regularly updated with this mechanism, very little is known about its inner workings given that microcode and the update mechanism are proprietary and have not been throughly analyzed yet.
In this paper, we reverse engineer the microcode semantics and inner workings of its update mechanism of conventional COTS CPUs on the example of AMD’s K8 and K10 microarchitectures. Furthermore, we demonstrate how to develop custom microcode updates. We describe the microcode semantics and additionally present a set of microprograms that demonstrate the possibilities offered by this technology. To this end, our microprograms range from CPU-assisted instrumentation to microcoded Trojans that can even be reached from within a web browser and enable remote code execution and cryptographic implementation attacks.
https://www.usenix.org/system/files/conference/usenixsecurity17/sec17-koppe....
which is about unencrypted AMD K8 microcode. It should throw some light on how the microcode works, and also why is it good to apply the fixes. Please note that I don't want another flamewar about why not doing the microcode updates would make my system more free.
There seems to be just one detail missing, the microcode triads are somehow obfuscated, and the paper does not tell how.
Happy hacking, Rudolf
In this paper, we reverse engineer the microcode semantics and inner workings of its update mechanism of conventional COTS CPUs on the example of AMD’s K8 and K10 microarchitectures.
Still wondering what was engineering reasons for these families behind such a practice as non-verified microcode updates. Also these families had very interesting uop-update behavior that could be called 'mu-ops cache', where under certain conditions malicious micro-ops could be cached forever, even if the 'good' update has been loaded afterwards.