I think I have read most of the news posts, and I have never seen any mention of AMD x86 processors. Has Purism considered AMD x86 processors for the Librem line?
1 Like
From what I can tell they are ok with any option that gives max performance but does not compromise our computers.
This means that all the code that drives the chip has to be open source or reverse engineered.
AMD laptop processors are hard to come by nowadays. The last processors that were known to not have PSP (AMD’s equivalent to Intel ME) were models before 2013. By Purism switching over to AMD models before 2013 (not even taking into effect the possibility of needing a separate APU due to the lack of integrated graphics), performance would be worse (the processor they’re using now is from 2015) and all the work done on the Intel i7-6500U would be lost.
So I doubt it but it’s possible I guess.
Is ASP/PSP really worse than ME? To me, it looks more like we just don’t know enough about it, and other parts of the AMD platform. Has anyone even tried to make a ASP/PSP_cleaner?
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 bit |
| 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) |
- You can see it in the die shot in AnandTech’s Mullins architecture article.
- From HardenedLinux article about ME.
- This is what me_cleaner does.
- Might be possible at runtime with exploits.
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
3 Likes
Or what about the other controllers that are needed; I don’t know enough to say which is better or worse:
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).
1 Like
As a new user, I am limited to 2 links per post; I have a full post with additional links at the Level1Techs forums or on Reddit, if you are trying to learn more about this stuff.
Whoa @torpcoms, that is a complete answer! Thanks for debunking clarifying the situation about the AMD ( P)SP vs Intel ME subject!
Edit: bad wording, as pointed out by @torpcoms
Someone did discover a stack overflow exploit in one of the internal functions which gave you code execution on the PSP (http://seclists.org/fulldisclosure/2018/Jan/12). It’s been patched out in newer versions, but I don’t believe that they have any kind of rollback protection for the firmware blob code (because there are very valid reasons for wanting to change your BIOS version up and down, especially on gaming systems).
So, given a sufficiently old BIOS version (or possibly even a new BIOS with the old AGESA code, not quite sure whether signatures are calculated over the whole thing or per-segment) and the correct exploit code, it should theoretically be possible to hijack the PSP during or after bootup and either run your own software on it or just hang the thing entirely by sticking it into an infinite loop.
1 Like
I wouldn’t call it debunking; with the research and reverse engineering we are starting to learn more about IME, but I hear little about ASP.
AMD did say they let third parties look at the PSP code, so there are multiple companies outside of AMD that have seen the code; but they are probably under NDA.
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-