

Updating a CPU’s Microcode 0x02: Update Process, Encryption and Microcode Blobs - mtnmts
https://blog.matan.me/2014/12/updating-cpus-microcode-0x02-encryption-problems-microcode-blobs/

======
userbinator
_Is it legal to reverse the CPU to figure out those things? According to
Intel, it’s not_

According to the basic law, it should be (DMCA and others notwithstanding):

[http://en.wikipedia.org/wiki/Semiconductor_Chip_Protection_A...](http://en.wikipedia.org/wiki/Semiconductor_Chip_Protection_Act_of_1984#Reverse_engineering_not_prohibited)

However, you're unlikely to be able to make any significant progress in a
reasonable amount of time due to the overwhelming complexity of a modern x86
CPU. The fact that there are many hidden/undocumented MSRs (Google 9C5A203A
for some nice links) makes it all the more difficult.

AMD microcode used to be unsigned, and it was possible to induce some... _odd
behaviour_ with it:
[http://www.securiteam.com/securityreviews/5FP0M1PDFO.html](http://www.securiteam.com/securityreviews/5FP0M1PDFO.html)

(Interestingly enough, no one at the time thought to hit it with a fuzzer and
see what could really be done... or if anyone did, they didn't tell. Also, I
remember a far more detailed version of this article was on the 'net around a
decade ago, but Google seems unable to find it, just like how information on
AMD's hidden MSRs was far easier to find a few years ago..)

~~~
makomk
[https://www.dcddcc.com/pubs/paper_microcode.pdf](https://www.dcddcc.com/pubs/paper_microcode.pdf)
seems to have more details on AMD's K8 microcode format.

------
sintax
Have a look at:
[http://inertiawar.com/microcode/](http://inertiawar.com/microcode/)

~~~
mtnmts
Wow, that's some fantastic work!.

Just to quote the conclusions of what Ben Hawkes found: Several previously
undocumented header fields have been identified and described. The results
suggest that microcode updates are authenticated using a 2048-bit RSA
signature. The RSA signature operation appears to be constant-time (i.e.
unaffected by changes to the supplied exponent, modulus or signature value).
Timing analysis reveals 512-bit steps correlating to supplied microcode
length. This is a common message block size for cryptographic hash functions
such as SHA1 and SHA2 The RSA signature was located, and the signed data is a
PKCS#1 1.5 encoded hash value. Older processor models use a 160-bit digest
(SHA1), and newer processor models use a 256-bit digest (SHA2).

------
mtnmts
Hey,

If you have any questions about the post or series, i'll be glad to to answer.

I'm still looking for how i can evolve this further, If anyone has done any
research into this himself and found a way around one of the problems that
exist, i would be very interested to hear!.

Thanks!.

~~~
kyberias
Interesting research. I was wondering why did you think that the microcode
might be in Verilog? Isn't verilog ascii? I suppose it's quite obviously some
custom Intel binary format.

~~~
mtnmts
You're right, it's almost definitely in some proprietary format, i mentioned
verilog just to give some basis of what kind of language it would be like, i
should have just mentioned VHDL's in general i guess.

~~~
makomk
The microcode format's unlikely to be like any kind of VHDL. It's probably
going to be a program consisting of a series of micro-ops for whatever
underlying architecture they're translating x86 into. So it'd have fairly
typical control flow structures like conditional branching, along with ways of
controlling dataflow paths in the CPU and dispatching operations to various
execution units. You can probably get some idea from 80s-era systems whose
microcode formats were publicly documented.

