AMD Reportedly Allows Disabling PSP Secure Processor With Latest AGESA

[torsionbar28]

Intel's IME is useful for stuff like "The system has hung and I'd like to reboot it now, but it's on the other side of the country and I don't want to have to pay someone to press the button."

But why bother with ME for this? Any decent server will have a separate management processor. Dell DRAC or HP ILO for example, that allow you to remotely power off/on a crashed server, remotely re-load the OS, remote hardware diagnostics, etc.

[torsionbar28]

So the problem is yet once again, Microsoft. Last thing I ever bought from Microsoft was Windows Vista

Vista, wow that must have been a disappointing purchase! The last thing I bought from MS was Windows NT 4.0 in 1998. Paid $299 for it full retail at the local CompUSA. I was so disappointed with how weak and shoddy it was, I switched to Slackware Linux (v3) for my main desktop right then, and it's been Linux ever since for me.

[soulsource]

But why bother with ME for this? Any decent server will have a separate management processor. Dell DRAC or HP ILO for example, that allow you to remotely power off/on a crashed server, remotely re-load the OS, remote hardware diagnostics, etc.

The ME is a separate management processor...

[bridgman]

But why bother with ME for this? Any decent server will have a separate management processor. Dell DRAC or HP ILO for example, that allow you to remotely power off/on a crashed server, remotely re-load the OS, remote hardware diagnostics, etc.

I believe the main reason for having integrated maintenance processors is to satisfy large IT departments that want to be able to remotely and automatically manage end-user laptop and desktop systems across multiple sites.

Rather than integrating the management processor into the CPU or chipset we recommend that OEMs use an external NIC like the Broadcom part described in the following link, which includes the core maintenance functions:

https://www.broadcom.com/products/et...ollers/bcm5762

https://www.amd.com/Documents/out-of...t-overview.pdf

[DrYak]

But why bother with ME for this? Any decent server will have a separate management processor. Dell DRAC or HP ILO for example, that allow you to remotely power off/on a crashed server, remotely re-load the OS, remote hardware diagnostics, etc.

Intel ME is basically Intel's own NIH proprietary take on this.
Also Intel being Intel as usual, due to their NIH-syndrome, this thing *IS NOT* IPMI compliant, Intel AMT is different (but covers the exact same use cases).

The main difference is that it's running on an ARC processor directly integrated into the motherboard chipset.
Meaning it's much more cheaper to add as a technology than a discrete chips as most IPMI implementations on more expensive hardware like servers.
Meaning they made it available accross the range on any chipset, including the ones inside laptops, small desktops, etc.
Which makes the admin at large corporations happy (they same ease of administration that IPMI brought to the server, Intel AMT bnrings it to laptops and desktops).

But that means that there's a closed source blob, that's not properly publicly audited, running on nearly all intel motherboard chipsets (even if the main CPU is shut down), with potential access to network, all the RAM, PCIe bus, firmware settings, flashing the firmware chip, etc.

Even if Intel AMT (the IPMI-like service) is turned off, Intel ME is still there (the extra cpu continue to exist no matter what the BIOS settings, continues to play an important role in booting, and continue to be able to communicate with the main OS.
(This has some useful functions : it's a chip that can serve as a TPM to store keys, and it can play role in DRM too to decrypt protected media as a chip that can't be directly manipulated by the end user).

It means that each time there's a known exploit found in the intelme firmware, some virus could try to send code to run on it. And that code won't shut down even when the main cpu is turned off. With potential network access and possibility to flash shit on the UEFI firmware chip (even while the PC sleeps).

The current approach is to cut it down : take the original intel-me firmware, and remove as many parts as possible and only keep the bare minimum (enough to pass the signature tests, enough to initialise the hardware, enough to keep the watchdog happy) while removing any excess functions (once the hardware is initialised, isolate the Intel ME and don't communicate with the external role).

Also, as a small details, it runs Minix (instead of the more usual "go-to" kernel when doing custom embed work : linux. but it doesn't really matter, except for Andrew Tanenbaum's bragging rights, because neither of them is GPLv3+)

In the specific case of AMD PSP :
- small technical difference: it's an ARM core.
- main use-case difference : on servers, IPMI fills the management role, AMD PSP doesn't play any role in that.
- AMD PSP play a role similar to the remaining Intel ME role :
- it helps booting and initialising the hardware.
- it can handle encrysption key
- it can handle DRM
- it can encryption of memory.
- because of the last point, by design it stays between the x86 cores of the main CPU and the RAM (@bridgman correct me if I got that wrong).

Because it has a priviledged position, it could in theory manage to get network access even if by design it's not used for this (IPMI is used instead).
It's scary because it too is running manufacturer-signed-only blobs (just like Intel's ME) and has total RAM access (by design, as it's supposed to be helping around full-mem encryption).
Any but that could be happening in its un-audited code could be potentially abused to gain full access of the machine for nefarious purpose, without the OS nor the main x86 cores noticing it.
(...but once you shut the machine down, this core gets powered down, unlike whatever discrete chip the motherboard manufacturer is using for IPMI).

The minimal solution would be for AMD to provide an alternative firmware (that they also sign) that does all the basic needed tasks to bring the system up, but then shuts down and doesn't interact at all. (Which would make you lose on the memory encryption feature, but at least you don't risk it getting exploited and starting to run undesired good).

The best solution would be for AMD to open the code to audit (at least, even if the don't actually opensource the current firmware) and to provide opportunity to end-users to run their own signed PSP firmwares they trust. (Similar to how UEFI SecureBoot allows you to upload your own key to run your own signed OSes instead of microsoft's OSes / microsoft-signed shims).
Meaning that if you don't the official AMD PSP fimware, you could still get an opensource one from libreboot (including features that you would like, like mem encryption) sign it, load your keys and get your AMD PSP to run that firmware.

Is there any advantage to embed a OS inside the CPU? Or, is there something can't be implemented effectively in the outside kernel?

With the exception of memory encryption: No, there's not a single thing that could not be done with discrete chips (that's how IPMI and Intel AMT are implemented).
And lots of things don't even require full access to the system (TPM can be implemented of a very simple standard link - like virtually every security card does) (In theory DRM could be implementend by specifying new standards of communication to send encrypted content to the DRM core, and the DRM core sending decrypted content straight to the video core without access by the CPU. It wouldn't require an omnipotent and omniscient inner OS. - And in a very few cases, it has been implemented so for some MPEG-2 hardware decoding cards back in the DVD era : you could send straight CSS-encrypted DVD content to the card, and the card would handle both the decryption and decompression)

Memory encryption it self could be implemented without the manufacturer-exclusive signing (as I've said above - similar to how SecureBoot can be configured in UEFI) so that if you don't trust AMD, you could get an alternative encryption firmware from libreboot. It would still require an on-CPU running firmware that can't be accessed by the OS.

Yep, this. We don't know what this option really does, and the description sounds more like it just "hides" the PSP from the OS. AMD is on record as saying the PSP is integral to the boot process, and in the best case here all we have is something like the HAP bit. In the worst case it's actually making security worse by hiding the potential backdoor from the user.

Again, we need to know from AMD (and check the actual code: it's ARM after all, it could be decompiled by some external experts).
But it could be entirely possible to give it an option, so the firmware running on the PSP only initialises the hardware needed for boot, and then stop completely from listening to the outside. No more communication = very few risks of exploits.

Vista, wow that must have been a disappointing purchase! The last thing I bought from MS was Windows NT 4.0 in 1998. Paid $299 for it full retail at the local CompUSA. I was so disappointed with how weak and shoddy it was, I switched to Slackware Linux (v3) for my main desktop right then, and it's been Linux ever since for me.

I've never bought any software from Microsoft.
Since late 90s I've been using Linux on the machine I own (mostly built from scraps, so I actually also didn't get a windows license "for free" with my machines).
Only acquired windows license for free through the universities for the occasional VM.
(And as a side node, this relience on Linux gave me good enough proficiency with unices to land me jobs in research)

[bridgman]

...
- it can encryption of memory.
- because of the last point, by design it stays between the x86 cores of the main CPU and the RAM (@bridgman correct me if I got that wrong).

I believe encryption is handled by the memory controller and PSP only touches the key(s).

Don't remember the TLA names offhand, but we have two modes of operation for memory encryption - one uses the same key for all memory, and the other uses per-process or per-VM keys (I forget which). The first mode probably does not require any involvement after boot; second one probably does.

[Niarbeht]

(This has some useful functions : it's a chip that can serve as a TPM to store keys, and it can play role in DRM too to decrypt protected media as a chip that can't be directly manipulated by the end user).

This makes me suspect we know what one of the exploit vectors will be.

[pq1930562]

Michael have you asked AMD for a statement yet? It's clearly a topic of high interest and the effects of this switch are not clear, nor the feature plans.

Maybe you yourself could just ask bridgman directly once he is done laughing about PlayStation Portable jokes?

[zboszor]

Damn it, you made spew water all over my desk in the office.

Speaking as a PSP owner.

FYI, software is licenced, but now owned.

PSP was always the abbreviation for Paint Shop Pro since 1990. Sony has nothing to do with it, only JASC and Corel and it doesn't run games.

What are everyone talking about??? :-D

[biffzinker]

The main difference is that it's running on an ARC processor directly integrated into the motherboard chipset.

The PCH for Broadwell was the last to use a ARC processor. Starting with Skylake Intel switched to using a x86 Intel Quark (P54C.)