4 ms·

Updating a CPU’s Microcode 0x02: Update Process, Encryption and Microcode Blobs

27 points by mtnmts 12y ago

mtnmts 12y ago
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 12y ago
  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 12y ago
    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 12y ago
      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.
sintax 12y ago
Have a look at: http://inertiawar.com/microcode/ http://inertiawar.com/microcode/
- mtnmts 12y ago
  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).
userbinator 12y ago
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_Act_of_1984#Reverse_engineering_not_prohibited http://en.wikipedia.org/wiki/Semiconductor_Chip_Protection_A... 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..)
- mtnmts 12y ago
  That's very cool, i wonder if the same extends to the microcode (.inc files) themselves. That AMD Research looks very, very very cool, Maybe i can get my hands on an AMD CPU and try it for myself.
- makomk 12y ago
  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.

27 points by mtnmts 12y ago

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 12y ago
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 12y ago
  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 12y ago
    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.

sintax 12y ago

Have a look at: http://inertiawar.com/microcode/ http://inertiawar.com/microcode/

mtnmts 12y ago
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).

userbinator 12y ago

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_Act_of_1984#Reverse_engineering_not_prohibited http://en.wikipedia.org/wiki/Semiconductor_Chip_Protection_A... 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..)

mtnmts 12y ago
That's very cool, i wonder if the same extends to the microcode (.inc files) themselves. That AMD Research looks very, very very cool, Maybe i can get my hands on an AMD CPU and try it for myself.
makomk 12y ago
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.