AMD vs Intel - proprietary controllers and code

Hardware Hub CPU
,
1

Here is me trying to summarise what I know about AMD and Intel’s proprietary controllers and code, especially:

AMD Secure Processor vs Intel Management Engine

The AMD Secure Processor (previously called the Platform Security Processor) and Intel’s Management Engine, are separate cores running signed code from AMD or Intel that have Direct Memory Access to the rest of your machine.

ASP ME
Location on processor chip1 in package/module; earlier versions were in northbridge2
Architecture ARM x86; earlier versions were ARC
OS TrustZone Minix; earlier versions ran ThreadX
Disable completely No No
Disable after startup Unknown using the HAP bit; earlier versions have AltMeDisable bit5
Modify signed code No4 No4
Prevent code being loaded Unknown Corrupt/remove certain ME partitions3
Operation without ROM? Unknown 30 minute recovery mode before forced shutdown
Network Access Unknown Yes (with Intel NIC)
  1. You can see it in the die shot in AnandTech’s Mullins architecture article.
  2. From this article about ME.
  3. This is what me_cleaner does.
  4. Might be possible at runtime with exploits.
  5. We have a thread about this.

This table is pretty much all I know about the two. Some things I couldn’t fit into a table row are:

  • Purism has mentioned that ME controls the ICC, and can cause problems with shutdown if misconfigured. This suggests some kind of deeper involvement with system initialisation that might not be replaceable even if ME could be completely removed.

  • In the Q&A portion of a talk on AMD x86 SMU firmware analysis at 31C3 (the response to the question at 47:58 about firmware verification) an AMD guy says this:

    The statement about verifying the BIOS code which loads the firmware is a statement with regard to newer products starting with the Mullins product that include a Platform Security Processor where the Platform Security Processor is the first micro-controller that comes up out of reset; for the older parts that do not have that, what Rudolf just said is correct.

    So on AMD chips, ASP starts executing first and verifies the x86 firmware.

  • Some people noticed that some AGESA (AMD’s version of FSP IIRC) updates added options to UEFI to stop it from talking to the ASP/PSP, but there is no indication this stops ASP/PSP (like HAP or AltMEDisable on ME) or affects it in any way.

    The UEFI screenshot from the original reddit thread says this specifically:

    BIOS PSP Support
    Description
    Enable/Disable BIOS PSP driver execution (including all C2P/P2C mailbox, Secure S3, fTPM Support)

    and the QR code is the URL: http://www.asrock.com/manual.asp?Model=AB350%20Pro4

Proprietary Controllers and Software Overview

I am mostly getting my information from the above mentioned SMU talk, Coreboot’s Binary Situation wiki page, and Purism’s Freedom Roadmap. If I am missing something, please tell me!

AMD

Component Location Architecture
AMD Secure Processor on processor chip ARM Cortex A5
System Management Unit (SMU) on chip module (not on die?) LatticeMico32
Integrated Microcontroller (IMC) southbridge MCS-51
USB 3 Controllers ? ?

Software is in AMD Generic Encapsulated Software Architecture (AGESA) package.

Intel

Component Location Architecture
Management Engine chip module (or northbridge earlier) ARC or x86
Platform Controller Hub southbridge ?

Software is the Firmware Support Package (FSP), Embedded Controller (EC) code, vBIOS code, and Management Engine (ME) code (some of which is burned into the chip and not on FlashROM).

I originally wrote this as part of a question for the Purism forums, although as a new user there I couldn’t include all my links; so the version here is more complete.
I also posted this to reddit’s /r/privacy, since they talk about this kind of stuff.

4 Likes
2

I forgot to mention this, in which AMD engineers mention that they have allowed more than one third party to review their PSP code. This is also where they mentioned that open source PSP is not in their future plans.

AMD response to questions on open sourcing PSP

I transcribed it myself from this Twitch recording, there is also a copy on periscope.

00:35:28

[Scott Aylor]

There’s another security related question, from the community is: When will you, or will you, release PSP source code?

So essentially kind of, the embedded hypervisor and firmware that we run inside of our platform security coprocessor for those that maybe aren’t as close to the technology.

I think our approach - I’ll kind of take this one and you guys can chime in as well - we’ve actually already completed multiple different audits from security companies, that we’ve hired to come in and essentially try and find threats, or vulner- excuse me, not threats, vulnerabilites in our PSP architecture as well as the PSP firmware that goes with it.

So that’s something that we’ve actually completed; actually earlier this year. So I think, we are looking to have people look at our security implementation from a software perspective and determine if there are vulnerabilities and weaknesses.

At this point it isn’t our plan to go kind of, put that out in the community, but we are taking the right steps and measures to ensure that we are having people that are experts, that kind of know what bad agents do, to really see if we have vulnerabilities.

[Forest Norrod]

Yeah, you know, so those are third party audits that we’ve contracted, but quite frankly, we’ve also had some customers charter their own; so not just AMD, but other customers and partners have performed their own third party audits of our firmware as well.

[Scott Aylor]

Yup. Very good.

00:37:00

The next questions really kind of pivot a little bit more to the hardware ecosystems-