GUIDE · PREVIEW
EDIT ON GITHUB →
GUIDE / HAR.45
source: docs/guide/hardware/AMD PSP.md
Hardware

AMD PSP

What It Is

The AMD Platform Security Processor (PSP) is an ARM Cortex-A5 core with TrustZone extensions, embedded directly on the main CPU die. Every AMD processor since the Jaguar/Puma microarchitecture (2013) and Zen (2017) includes one. Like Intel ME, you cannot buy an AMD system without it.

The PSP's primary role is platform security: it initializes DRAM before the x86 cores start, verifies firmware integrity, provides the hardware random number generator (backing RDRAND), and offers firmware TPM (fTPM) services.

Unlike Intel ME, the PSP does not have its own network stack and cannot independently send or receive network traffic. It is a security processor, not a management processor.

How It Works

Hardware

The PSP is an ARM Cortex-A5 (32-bit, ARMv7-A) with TrustZone. It sits on the CPU die itself -- not on a separate chipset like Intel ME. It has its own SRAM and access to system resources. Its firmware is loaded from the SPI flash chip at power-on.

Boot Role

The PSP is critical to the boot process in a way that Intel ME is not:

  1. PSP wakes up first when power is applied
  2. PSP initializes DRAM (the x86 cores cannot do this themselves on AMD)
  3. PSP verifies the integrity of the SPI flash firmware
  4. PSP releases the x86 cores from reset only after initialization completes

Without a functioning PSP, the system cannot POST. The x86 cores physically cannot start because they depend on the PSP to set up memory.

Security Functions

  • Secure boot verification: Validates firmware images before allowing them to execute
  • fTPM (firmware TPM): Provides TPM 2.0 services in firmware, eliminating the need for a discrete TPM chip. Most AMD consumer systems use fTPM rather than a hardware TPM.
  • Hardware RNG: The RDRAND instruction on AMD CPUs is backed by the PSP's random number generator
  • Memory encryption: SEV (Secure Encrypted Virtualization) and SEV-SNP use the PSP to manage per-VM encryption keys. The PSP generates and manages these keys; the x86 cores and hypervisor never see them in plaintext.

Security Considerations

Cannot be disabled or neutralized. Unlike Intel ME, which can be stripped with me_cleaner and disabled via the HAP bit, the PSP is required for the CPU to boot. There is no equivalent to me_cleaner for the PSP. AMD added a "BIOS PSP Support" option in some AGESA updates that reportedly disables some PSP functions after boot, but not all motherboard vendors expose this option, and its effectiveness is debated.

Less attack surface than Intel ME. The PSP lacks a network stack, so it cannot be attacked remotely (unlike ME, which has its own MAC address and TCP/IP). It also runs a simpler firmware without the ME's web server, Java runtime, or management features. The attack surface is primarily physical or via malicious firmware updates.

Firmware is opaque. Like Intel ME, the PSP firmware is signed and encrypted by AMD. Independent auditing is limited. AMD has been less forthcoming than Intel about the PSP's internals, though some researchers have made progress reverse-engineering the boot ROM.

fTPM concerns. Systems using fTPM (most AMD consumer hardware) have their TPM services running on the PSP. A PSP compromise means a TPM compromise. A discrete hardware TPM is isolated from the CPU and harder to attack -- FortrOS prefers discrete TPMs when available.

How FortrOS Uses It

FortrOS treats the PSP as the hardware security foundation on AMD systems:

  • fTPM or discrete TPM: If the system has a discrete TPM, FortrOS uses that. If only fTPM is available, FortrOS uses it but notes the PSP dependency in the node's metadata.
  • SEV-SNP for confidential VMs: On EPYC processors with SEV-SNP, the PSP manages per-VM encryption keys. FortrOS's reconciler uses this for tier 3/4 VMs when available. See 09 Running Workloads.
  • No neutralization path: Unlike Intel ME, the PSP cannot be disabled. FortrOS accepts this as a hardware constraint. Government deployments that require full firmware auditability may prefer Intel hardware with coreboot (ME can be neutralized) or RISC-V (no management processor at all).

Remote Management on AMD

The PSP does not provide remote management (no AMT equivalent). For out-of-band management on AMD systems, the options are:

  • AMD DASH: A DMTF standard for desktop/mobile management. Implemented via the network controller or BMC, not the PSP. Available on AMD PRO-branded business platforms. See Out-of-Band Management.
  • IPMI/BMC: Server-class AMD systems (EPYC) typically have a separate Baseboard Management Controller. This is standard server hardware, not AMD-specific.
  • No OOB on consumer: AMD Ryzen consumer systems have no built-in out-of-band management. FortrOS nodes on consumer AMD hardware require physical access for recovery.

Alternatives

Intel systems: Have Intel ME instead, which includes optional remote management (AMT) but also a larger attack surface (network stack, DMA).

RISC-V: No equivalent management/security processor. The RISC-V ISA is open, and no vendor-mandated co-processor exists. This is the long-term path for users who want fully auditable silicon.

Discrete TPM: Can supplement or replace the PSP's fTPM function. Does not eliminate the PSP itself (still required for boot), but isolates TPM operations from PSP compromise.

Links