What is known about the capabilities of AMD's Secure Processor?

Question

I've found a fair amount of research about what Intel's ME does, including the "Intel x86 considered harmful (Chapter 4 is about ME)" survey paper by Joanna Rutkowska, but I'm having a much harder time finding information about AMD's Secure Processor (previously known as PSP).

Some people have asserted that AMD PSP is "as bad as" or "worse than" the ME. (For example, there's an oft-cited page on the libreboot project's site that claims a lot of things about PSP, but I haven't yet found independent corroboration of many of those claims, and libreboot's perspective is clearly different from that of a practical security researcher.)

Ultimately, what I want to answer for myself is: if one's threat model assumes that AMD hasn't pre-backdoored its CPUs/APUs in the factory, how risky is the Secure Processor as a vector for future backdooring (like the "ring -3 rootkits" demonstrated on Intel), either by AMD or a third party, and is that threat mitigable?

But less subjectively, I'd like to know what capabilities have already been seen on the Secure Processor, and how that compares to what's known about ME:

• Has it been used for remote management similar to Intel's AMT?
• Is it known to have its own network stack?
• Does it have software-updatable firmware, and how is that firmware secured?
• Have there been any known exploits targeting it yet, or any public research done on its firmware?
• On what grounds could one say that the situation with AMD PSP is "better" or "worse" than with Intel ME?

Answer 1

I was interested in the same issue and did some preliminary research. I'll try to answer some of the questions, though as a non-AMD engineer I cannot be certain.

Does it have software-updatable firmware?

Yes, it does. This firmware is part of the AGESA (AMD Generic Encapsulated Software Architecture), a binary blob distributed from AMD to UEFI firmware vendors. Also to coreboot, where they come with release notes The PSP section mentions PSP version numbers for different platforms. This suggests that they are updatable.

and how is that firmware secured?

I have not been able to extract the firmware code, and don't know how it is protected. A possible indication would be how the SMU firmware is protected: with a HMAC-SHA in the header, with hidden secret key (see the Rudolf Marek's presentation).

• Pointer for further analysis: stoney ridge PSP blobs in coreboot.

Has it been used for remote management similar to Intel's AMT?

It is impossible to know what it has been used for. However, my findings suggest that remote management is not the primary purpose (unlike Intel's ME). What I've find it does:

• The PSP plays a role in the boot process of the CPU (this is often-quoted, so I won't repeat).

• The PSP offers the fTPM (firmware based TPM) API for private key management.

• The PSP does key managment for SEV (Secure Encrypted Virtualization API), VM memory encryption. This uses an API to the PSP. To see the nuts and bolts there is a Linux patch RFC to introduce support.

• The PSP can be used for cryptographic offloading. Support for this landed in the Linux kernel under drivers/crypto/ccp.

However: there is evidence that code can be loaded dynamically,

• Loading of "trustlets" in coreboot. Pointer for further analysis: PSP library in coreboot
• A comment "Command to load Trusted Application binary into PSP OS" in drivers/gpu/drm/amd/amdgpu/psp_gfx_if.h in the Linux kernel. This might deal with a different PSP on the GPU die, but as it is AMD code, even then there might be overlaps.

Is it known to have its own network stack?

No, it is not known to have a network stack in the stock configuration. All APIs seem to be facing the CPU, not the outside world.

Knowing how these processors are designed with vague specifications from "enterprise customers" and DRM vendors, it might be possible to load remote management modules, with network stack. However, nothing that I've found proves that conclusively.

Have there been any known exploits targeting it yet, or any public research done on its firmware?

There is a public vulnerability in the fTPM API. I could not find any public research on the firmware.

On what grounds could one say that the situation with AMD PSP is "better" or "worse" than with Intel ME?

At least the AMD security processor does not provide a remote management API out of the box (as far as we know), unlike Intel ME. To turn it into a network-listening backdoor, OS software has to provide further modules, or maybe even compromise it.

However, as we've found, it is a black box with very little public research put into it. In cryptography a system gains trust after it is often analyzed and no vulnerabilities are found. Security by obscurity is not acceptable. Unfortunately no one holds security processors to Kerckhoffs's principle.

Answer 2

So what I would say is anything that provides direct memory access and essentially does processing on behalf of the processor is a whole other set of threat surfaces you are introducing to the computing platform. So I would say the threat surface is similar if not the same.

The way that PSP is supposed to operate, in many ways mimics ME but, it will also be taking part in cryptographic operations given that seems to be its primary focus. There aren't current attacks in the wild on the platform yet that are being talked about.

The part that leads me to believe it will likely be leveraged in that manner is a teaser: anti-theft software is one of the features PSP is supposed to enable... Almost all cases of this take advantage of ME or cludgy UEFI shims, if this is meant to be more of the same then I would assume some resident/offline management capability for the PSP system on chip.

There is nothing in the spec that speaks to a networking stack directly, but there is a call out to interacting with 'IO' which could be a stub left for that.

It would also surprise me if AMD ignored a feature from their main competitor that's been around for nearly over a decade. But that's not conclusive.