Yesterday we inspected Intel ME, the small government below the host operating system.

Today the AMD loyalist enters the room and says:

“At least I am free from Intel.”

The Supreme Leader points to the floor.

There is another office underneath.

AMD calls it the AMD Secure Processor.

Older documentation and public discussion often call it PSP, the Platform Security Processor.

It is not Intel ME.

It is not the same product.

But it occupies the same uncomfortable category:

a dedicated security processor below the operating system, involved in platform trust before your kernel has opinions.

I. What AMD PSP Actually Is

AMD’s current security materials describe the AMD Secure Processor as a dedicated on-chip security processor at the core of AMD PRO security architecture.

In practical terms, PSP/ASP is a security subsystem integrated into AMD platforms. Its exact behavior varies by generation and product family, but it participates in the platform’s security and trust model.

Publicly associated responsibilities include:

• secure boot chain participation
• firmware authentication
• cryptographic operations
• firmware TPM support
• platform security services
• roots of trust for features such as SEV on server platforms

This is the correct framing:

not “AMD copied Intel ME.”

not “AMD has no hidden computer.”

The correct sentence is:

AMD has its own platform security processor, with its own architecture, firmware, trust roles, and audit problems.

The other empire built its own ministry.

II. The Name Problem

The name changed enough to confuse civilians.

Name	Where you see it	Meaning
PSP	older/common public name	Platform Security Processor
AMD-SP	shorthand used by some technical communities	AMD Secure Processor
ASP	AMD Secure Processor, newer branding	platform security processor family
fTPM	firmware TPM functionality	TPM services implemented in platform firmware/security processor context

This article uses PSP because the citizens still say PSP.

The ministry may rebrand.

The basement remains.

III. Intel ME vs AMD PSP

The lazy comparison says:

“Intel ME and AMD PSP are the same.”

No.

The useful comparison says:

“They are different vendor platform security engines that both complicate the fantasy that the host OS owns the whole machine.”

Aspect	Intel ME / CSME	AMD PSP / ASP
Vendor	Intel	AMD
Category	security/manageability engine	platform security processor
Remote management	Intel AMT on supported vPro systems	not the same AMT model
Firmware relationship	ME region commonly shares SPI flash with host firmware	PSP firmware/platform initialization delivered through vendor/OEM firmware stack
TPM role	Intel PTT exists on Intel platforms	AMD fTPM exists on AMD platforms
User concern	closed lower-layer firmware with management/security roles	closed lower-layer firmware with security/trust roles

The exact feature sets differ.

The political lesson rhymes.

Modern x86 is not two vendors fighting over freedom versus tyranny.

Modern x86 is two vendors shipping trust machinery below your OS because the platform became too complex, too attacked, and too commercially managed to remain a simple CPU plus BIOS.

IV. Firmware TPM: The Key Clerk

Many users meet AMD PSP through fTPM.

TPM means Trusted Platform Module. It stores or protects measurements, keys, and platform state used by features such as BitLocker, measured boot, attestation, and other security mechanisms.

A TPM can be discrete hardware.

Or it can be firmware-backed.

AMD platforms often expose AMD fTPM, tied to AMD Secure Processor firmware.

This is why BIOS updates, AGESA updates, and OEM firmware releases can affect TPM behavior.

AMD security bulletins have documented fTPM-related issues and mitigations, including firmware TPM vulnerabilities and updates distributed through OEM BIOS/firmware updates.

The practical advice is boring and therefore correct:

• update system firmware from the OEM
• understand BitLocker recovery-key implications before firmware/TPM changes
• do not clear TPM state without knowing what keys depend on it
• treat fTPM as platform security state, not a toggle for vibes

The TPM is not a sticker.

It is a clerk holding keys.

Do not fire the clerk while the vault is locked.

V. Secure Boot And Early Authority

AMD PSP/ASP participates in platform trust.

On modern AMD platforms, the security processor is involved early, before the operating system boots.

A simplified chain looks like this:

reset
  |
AMD Secure Processor / ROM / firmware trust logic
  |
platform initialization firmware
  |
UEFI / boot firmware path
  |
bootloader
  |
operating system

This diagram is simplified because every real platform is a stack of vendor implementation details, OEM choices, firmware packages, AGESA versions, and board-specific policy.

But the hierarchy is enough:

the OS is not first.

The OS is the official who arrives after the security office has already opened the building.

VI. PSP And The Flashrom Problem

With Intel, flashrom often reveals an obvious flash map: descriptor, ME region, BIOS region, GbE region.

With AMD, the layout and tooling story differs.

The general lesson remains:

platform security firmware lives in the firmware ecosystem and may be delivered through BIOS/UEFI images, AGESA packages, OEM updates, and platform initialization components.

That means a firmware dump is still evidence.

But do not blindly apply Intel mental models to AMD images.

Intel instinct:
  find IFD
  identify ME region
  reason about descriptor access

AMD instinct:
  inspect vendor firmware layout
  identify PSP/AGESA-related components if tooling supports it
  verify OEM update provenance
  do not assume Intel region names exist

The Republic endorses careful reverse engineering.

It does not endorse pretending every firmware image is the same empire wearing a different hat.

VII. The Server Angle: SEV

AMD PSP becomes especially important in server security because AMD’s confidential-computing features rely on platform trust anchored below normal host software.

AMD SEV, SEV-ES, and SEV-SNP are designed to protect virtual machines from parts of the host environment. These features depend on keys, firmware, attestation, and secure processor behavior.

This is why AMD PSP is not merely laptop paranoia.

It is part of the trust story for cloud infrastructure.

The customer asks:

“Can the cloud provider read my VM memory?”

The answer involves:

• CPU features
• memory encryption
• firmware
• attestation
• AMD Secure Processor behavior
• hypervisor boundaries
• update state

The packet people had BGP.

The cloud people have attestation.

Both are paperwork systems that decide where trust is allowed to travel.

VIII. The faulTPM Lesson

AMD fTPM has had real research attention.

The faulTPM work showed that physical voltage fault injection attacks could compromise AMD fTPM secrets on studied platforms. AMD assigned CVE-2023-20589 and published security guidance.

This does not mean every random website can steal your BitLocker key.

It means the firmware TPM is a real security component, with real attack surfaces, real firmware updates, and real physical-threat assumptions.

The lesson is not:

“PSP bad, panic.”

The lesson is:

“If your keys depend on platform firmware, platform firmware is part of your key management system.”

The clerk holding the keys must also be audited.

IX. What AMD Got Right And Wrong

AMD deserves credit for AMD64, Zen, and forcing Intel to stop pretending IA-64 was destiny.

That does not exempt AMD from platform trust criticism.

Good reason PSP exists	User discomfort
secure boot and firmware validation	closed firmware below the OS
cryptographic services	limited independent auditability
fTPM support	firmware bugs can affect keys
SEV trust roots	cloud trust depends on opaque firmware
platform recovery/security	OEM update dependency

The mature position is not fanboy absolution.

The mature position is:

AMD PSP solves real platform security problems while creating real ownership and transparency concerns.

This is also true of Intel ME.

The difference is architecture and exposure, not the fact that both vendors built basement offices.

X. The Real Story (Suppressed)

Officially, PSP means Platform Security Processor.

Unofficially, the first proposed name was:

Plausibly Smaller Police.

Marketing objected.

Engineering proposed:

Please Stop Peeking.

Legal objected.

So AMD settled on terminology involving security, platform, and processor, because all three words sound like they have already passed compliance review.

The internal launch slide reportedly said:

Intel has a hidden ministry.
We need one too, but with better power management.

This is probably false.

It is also spiritually accurate.

XI. The Lesson

AMD PSP is not Intel ME with a different logo.

It is AMD’s own answer to the same modern platform problem:

the machine must verify, measure, decrypt, attest, initialize, and recover before the user’s operating system can even begin pretending it is sovereign.

The user owns the laptop.

The vendor owns firmware keys.

The OS owns the process table.

The security processor owns first contact.

That is the uncomfortable stack.

The decree is simple:

• do not pretend AMD lacks a below-OS security processor
• do not pretend it is identical to Intel ME
• treat fTPM as key infrastructure
• update firmware deliberately
• read images before theorizing
• remember that the basement exists even when the door has AMD colors

Next we return to Sony and the PS3 Cell:

the architecture that made developers do archaeology.

— Kim Jong Rails, Supreme Leader of the Republic of Derails