4 ms·

A team from Ruhr University Bochum reverse-engineered the microcode for the AMD K8 and K10 to implement custom microcode programs, they describe how they revers

A team from Ruhr University Bochum reverse-engineered the microcode for the AMD K8 and K10 to implement custom microcode programs, they describe how they reverse-engineered the ROM here: https://www.syssec.ruhr-uni-bochum.de/media/emma/veroeffentlichungen/2018/08/20/constructive_ucode-CCS18.pdf https://www.syssec.ruhr-uni-bochum.de/media/emma/veroeffentl.... The problem with reverse-engineering on newer CPUs is that on both Intel and AMD the updates are now protected with cryptographic authentication, so you can't run arbitrary custom microcode to aid in understanding what it does. And as others have mentioned, the hardware complexity and small feature sizes make reverse-engineering the microcode engine or ROM by physical inspection much harder than on the K8. I expect it will be achieved at some point, though.

jfkebwjsbx 7y ago
Even if you manage to understand the microcode, there could be custom behavior in the hardware logic, right? So I would guess studying the microcode does not lead to proving there is nothing else going on. I am no EE, though.
- cat_easdon 7y ago
  Yeah, that's right - you could prove the absence of malicious microcode, but not the absence of hardware trojans, implants, etc. There are also the embedded microcontrollers to deal with (e.g. the Management Engine, Innovation Engine, and Power Management Controller on Intel).
paulmd 7y ago
Ryzenfall and Masterkey together provide a complete break of the PSP authentication with arbitrary code execution if you are running a vulnerable AGESA. You will of course have to flash downwards to a vulnerable version but it should give you what you need. Also, as this was fixed prior to Zen2 then you wouldn’t be able to test their newer chips. Basically AMD has a buffer overflow in a SMM call and they conveniently signed an empty PSP module payload that will be executed nevertheless. https://youtu.be/QuqefIZrRWc https://youtu.be/QuqefIZrRWc

jfkebwjsbx 7y ago

Even if you manage to understand the microcode, there could be custom behavior in the hardware logic, right? So I would guess studying the microcode does not lead to proving there is nothing else going on. I am no EE, though.

cat_easdon 7y ago
Yeah, that's right - you could prove the absence of malicious microcode, but not the absence of hardware trojans, implants, etc. There are also the embedded microcontrollers to deal with (e.g. the Management Engine, Innovation Engine, and Power Management Controller on Intel).

paulmd 7y ago

Ryzenfall and Masterkey together provide a complete break of the PSP authentication with arbitrary code execution if you are running a vulnerable AGESA. You will of course have to flash downwards to a vulnerable version but it should give you what you need. Also, as this was fixed prior to Zen2 then you wouldn’t be able to test their newer chips. Basically AMD has a buffer overflow in a SMM call and they conveniently signed an empty PSP module payload that will be executed nevertheless. https://youtu.be/QuqefIZrRWc https://youtu.be/QuqefIZrRWc