Security Engineer Jevin Sweval has disclosed a security exploit for older (pre-Zen) AMD SMU coprocessors. The hacker mentions he was not able to get the exploit to work on PS4, although it could work in theory, since the PS4 processor matches the vulnerability’s requirements. (more details below)

What’s SMU?

The acronym SMU might ring a bell, that’s because we mentioned it a few days ago, as it appears progress is being made on hacking that coprocessor on the PS4. It is unclear if the progress mentioned then referred to today’s disclosure, or if it is a separate exploit.

AMD System Management Unit (SMU) is a thermal and electric management unit found in modern AMD x86 processors. The system management unit (SMU) is tasked with the job of continuously sampling sensory data and making rapid corrections to various circuits on the chip. One such example is the control of the boost circuit we detailed earlier. Additional tasks include voltage level control which is supplied as targets to the power supply monitors (PSMs), C-state boosts, thermal management ensuring the chip does not exceed the spec temperatures, and electrical design current management which ensures the current draw does not exceed the specs of the external voltage rails.

In particular, the PS4 SMU shouldn’t be confused with SAMU (Secure Asset/Access Management Unit), a separate processor that handles lots of the encryption/decryption tasks on the PS4.

What’s this LM32 Exploit?

Older AMD SMU coprocessors (including the one on the PS4) are based on the LM32 Architecture. Jevin has devised a technique to extract the HMAC encryption key from the SMU’s firmware, allowing to sign one’s own Custom Firmware for the SMU. Of note, such a “custom firmware” is not the same as a PS4 Custom Firmware, as we’ve explained in the other article. However, getting full control of the SMU can help an attacker get privileged access to other parts of the CPU/APU and memory. In other words, it can be an entry point for further hacks.

As for the exploit itself, Jevin has a full writeup available for those who want to dive deeper. Long story short, he summarizes it this way:

It turns out AMD integrated the LM32 so completely that it retained its debug functionality.  […] From within the SMU you can turn off the read/write SRAM protections and read out the bootrom.

SMU SRAM Activity

The Zen processors (including the PS5) rely on the Xtensa architecture, and are therefore not impacted by the exploit.

Can PS4 be impacted by this exploit?

Unfortunately, when asked if the PS4 is impacted, the hacker basically said it’s very unlikely:

I don’t own an Xbox One and haven’t tested there. PS4’s APU/SMU has some oddities that prevents this attack In its current form (or I’m just making a stupid mistake somewhere). (source)

Nevertheless it might be worth having some other pairs of eyes on the issue, just in case.

More interestingly however, Jevin dives into details for the PS4, and it seems he has a few more tricks up his sleeves (emphasis mine):

Exploit lets you read/write to x86 DRAM physical and use the serial port. That would allow a 4 wire “modchip” (some uC with VCC, GND, RX, TX) to talk over UART to stubs injected in a patched SMU FW that perform patches usually done from a userland/WebKit kexploit.

There’s not enough SRAM to hold all the patches needed, thus the requirement of a uC talking to SMU proxy stubs. Through limited testing (it’s a PITA compared to just using Linux on a PC) on the PS4, the writes to some of the SMU BP regs are ignored/blocked. Maybe AMD got wise?

But we have the PS4 SMU bootrom and FW dumped via other means and can analyze it for other vulns that might allow code execution. I’m also working on a PCIe MITM like marcan did to better understand the boot process of PS4 over PCIe instead of the normal read from SPI flash. (source)

Source: Jevin Sweval