Seems interesting; PSP is their IME equivalent; considered to be less bad but that’s until that’s exploited too (or we hear about known attack vectors)…
As well as a mention by @catsay in the AGESA PSA thread:
Edit: Gah! those are both the same type of link! Why is Discourse embedding one but not the other!?!
It disables one of the PSP DXE Drivers in the BIOS code. (fTPM)
But there are many many many many more parts to the puzzle. I wouldn’t even begin to say this “Allows disabling PSP” due how much of an Integral Part the Platform Security Processor is.
Likely some of the 3 below and including the highlighted one are involved.
Also take note of AmiAgesaDXE as opposed to AmdAgesaDXE
Here’s a dump of all ~240 something the Readable DXE Drivers and other registered modules in the average Ryzen BIOS taken from ASRock X370 Gaming K4 version 4.1
(4.1 being the Agesa 22.214.171.124 version that has since been pulled from a lot of Firmware sites.)
Also the as yet 268 unknown GUID’s:
And all this is just from one Volume Image subsection in the firmware file
Intel FUBAR ... again - Kernel memory leak in nearly every Intel CPU of the last decade (Spectre hits everyone, Meltdown still Intel exclusive)
A lot of the UEFI code in AMD’s BIOS is plain edk2 for which you can make modules.
[Defines] INF_VERSION = 0x00010005 BASE_NAME = BootScriptExecutorDxe MODULE_UNI_FILE = BootScriptExecutorDxe.uni FILE_GUID = FA20568B-548B-4b2b-81EF-1BA08D4A3CEC MODULE_TYPE = DXE_DRIVER VERSION_STRING = 1.0
I haven’t built my own to compare, but I bet a lot of these are very close to each other.
Even at best, if there was some way to shut down the AMD Secure Processor/Platform Security Processor (ASP/PSP), this would be sort of like the HAP/AltDisableME method of disabling Intel ME; which still leaves you open to exploits before ME disables itself:
Unfortunately, AMD’s ASP/PSP looks like it is more tightly integrated into the processor than Intel’s ME. In a 31C3 AMD x86 SMU firmware analysis talk, there is this response given by an AMD guy responding to the question at 47:58 about firmware verification:
The statement about verifying the BIOS code which loads the firmware is a statement with regard to newer products starting with the Mullens 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.
The Libreboot FAQ also mentions this:
The Platform Security Processor (PSP) is built in on all Family 16h + systems (basically anything post-2013), and controls the main x86 core startup. PSP firmware is cryptographically signed with a strong key similar to the Intel ME. If the PSP firmware is not present, or if the AMD signing key is not present, the x86 cores will not be released from reset, rendering the system inoperable.
On Intel platforms, the machine can at least boot without the ME firmware being loadednote 0, albeit only for 30 minutes. Running any x86 code on a modern AMD chip is impossible without the ASP/PSP.
note 0Actually, that might be the situation on modern Intel chips as well, since part of the ME firmware is burned into ROM, rather than in FlashROM. Maybe that chip-ROM code is critical in bringing x86 cores up too.
In your list, there are 13 entries with PSP in their name and only one with AGESA, namely
AmiAgesaDxe. Assuming that AGESA is only in that package, the option to unload
AmdPspFtpmDxe and possibly other drivers should have nothing to do with AGESA, right?
I transcribed the relevant bits from the image, for anyone else not wanting to reopen it each time to check the wording,
BIOS PSP Support
Enable/Disable BIOS PSP driver execution (including all C2P/P2C mailbox, Secure S3, fTPM Support)
QR code is:
That list is only a very basic list of modules that I decoded. Most of these are just UEFI DXE Drivers. There are many more unknown GUID’s and large raw binary blobs in the firmware whose purpose is unknown to me.
Some of it looks like ARM code.
Cool thing about UEFI is that DXE drivers and lots of other parts of it are based on Windows PE (Portable Executable) structure.
The ARM code could be for ASP/PSP, or maybe AMD switched the SMU from LatticeMico32 to ARM, and this is its firmware? The SMU talk I linked earlier also mentions USB3.0 controllers and an Integrated Microcontroller having mystery firmware; maybe one of those is ARM?
Hmm, I would prefer ELF, since ELF is almost universal, apart from OSX (Mach-O) and Windows (PE). From what I remember, most of the TianoCore devs are/were primarily working in Visual Studio, which probably explains that.
i too would like to disable my playstation portable
The PSP coprocessor on Ryzen is more powerful than a Playstation Portable.
My guess is that this never happened.
I tried to find a PSP disable on my x370 and it doesn’t exist.
I think it is disabled on my X470 board? I’ll need to check next time i reboot it.
I am so happy that this option exists.
I have a MSI X399 Creation motherboard and an AMD threadripper 2950x and after watching a video on PSP I have been feeling bad and googling for a solution for days.
Then, I go into my bios, enable advanced overclocking options, and I see the setting to disable it! (supposedly).
I feel so much better, it’s like a huge weight was lifted off of my back.
But can we actually test whether it really is disabled?
Only way to be sure is to build your own fab to build your own cpus (and motherboards, NICs, RAM, etc.) of your own design with. And run your own self-coded-from-machine-code OS with. From storage you made yourself.
I thought AMD were the good guys?