Compromising Between Intel Without Coreboot or AMD PSP

General Discussion
1

As it currently stands, Joanna herself has found Intel ME to be a depressing[1] situation[2]. This was in fact a change of heart, compared to her earlier views[3].

Fortunately, neutralising parts of the ME is now possible. For this reason, obtaining a Qubes hardware certification[4] makes it mandatory. So this is currently the ideal choice.

Unfortunately, this choice is also limiting. A highlight for example are the Framework laptops, where the manufacturer still has not agreed to prioritise free firmware, despite years of persistence[5] from their potential customers and broader community.

On the other hand, there is the choice for an AMD processor. Their equivalent of ME is called PSP. As of 2023, security researcherers such as Christian Werling[6], Alexander Eichner and Robert Buhren[7] have reported that PSP is lacking a network stack and as such, it doesn’t represent a priority for similar efforts to neutralise it. But at the same time, the maintainer of the Coreboot fork Libreboot, seems to express equal concern[8] for PSP as she does for ME; while indeed she mentions the existence of a built-in network interface only in the case of ME, she does say that PSP has access to the standalone network controller, if one is present on the system. However, this does not have equivalent implications for security; comments are welcomed.

In any case, AMD comes with unique and definitive issues. First, as Qubes themselves emphasise[9], AMD is significantly less efficient than Intel regarding microcode updates, which in fact introduces new security risks. Notably, the user depends on hardware vendors (rather than on AMD alone) to eventually distribute the required update.

Secondly, on multiple online forums there are generic reports of “bugs” and “instability” on various systems (not necessarily Qubes OS) running AMD, which seem to be attributed to a lower standard in the manufacturing process, but also to less support at the software level. Without direct experience, it’s difficult for me to know the extent of those issues and their relevance. This is another point where I hope the community is able to provide clarity.

Finally, it should be noted that AMD also offers a cost advantage.

I hope to hear opinons on the accuracy of this assessment, in particular regarding any omission of relevant variables. As previously mentioned, a comparison between the usability of AMD vs. Intel would be valuable, with a particular focus on being specific (e.g when using Qubes, are rare and brief system freezes to be expected, or more likely regular crashes?). But most importantly, how does standard Intel ME and standard AMD PSP actually compare, from a security point of view?

Thank you

  1. Intel x86 considered harmful (new paper) | The Invisible Things Blog ↩︎

  2. https://blog.invisiblethings.org/papers/2015/x86_harmful.pdf ↩︎

  3. More Thoughts on CPU backdoors | The Invisible Things Blog ↩︎

  4. Certified hardware | Qubes OS ↩︎

  5. [RESPONDED] Coreboot on the Framework Laptop - Framework Laptop 13 - Framework Community ↩︎

  6. Question, regarding psp, · Issue #54 · PSPReverse/PSPTool · GitHub ↩︎

  7. Select instance - Invidious ↩︎

  8. Libreboot – Frequently Asked Questions about Libreboot firmware ↩︎

  9. System requirements | Qubes OS ↩︎

3 Likes
2

I normally overwrite the IME with a custom operating system that I trust if I have the availability to enable the write mode on the IME. Same with AMD’s version.

They are all very insecure.

1 Like
3

No significant difference, as both of them contain firmware black boxes with elevated administrative privileges that cannot be completely and permanently revoked by the user.

2 Likes
4

I noticed that the reasons you gave are theoretical in style, so I must ask: is there a specific, more practical angle as well? Note that the context of this thread is trying to find a relative compromise, when the ideal option (addressed in the second paragraph) isn’t available.

Here is another source which I omitted to include in the first post. It’s a less alarmist (but still equivocal) comparison of Intel ME and AMD PSP. It addreses the networking aspect.

1 Like
5

Playing the devils advocate a little bit:

  1. You realize that the articles linked in Footnotes 1 and 2 are 10 years old? And in the meantime, there has not been one verifiable instance of ME abuse?
  2. The coreboot/libreboot alternatives are more or less crippling your hardware.
  3. AMD (as a company) is not in any way more ethical than Intel is. If the Government (yes, that Government) asks them to jump, they ask “how high?” or lose all access to Government (-related) contracts.
3 Likes
6

Same link on my Anonymous Overflow instance:

I need to address one of your prior statements first:

Qubes-certified hardware does not require Intel ME to be neutralized/disabled via HAP bit.

Sure, Intel ME has more security researchers discovering vulnerabilities within it compared to AMD PSP:

2 Likes
7

Thanks for that.

If I understand you correctly, Intel ME has received more scrutiny from security researchers, which exposed several backdoors, and those have since been fixed. And as a result, this makes Intel ME more battletested.

On the other hand, AMD PSP has not received this level of scrutiny. However, this might be due to the fact it lacks a network stack (as mentioned earlier), so its functionality appears to be more limited to begin with. Rather than a large and battletested attack surface, it has a smaller one, which could be argued to be an inherent advantage for security.

Is my reasoning here correct? If so, it’s still very much equivocal and I don’t feel closer to deciding whether Intel or AMD would be a better choice for a new machine. Before I conclude it’s a “pick your poison” situation and therefore reasoning this out can’t help more than a coin flip - I’d like to hear more comments.

I’ll link the following quote from another thread back in Aug 2023, which adds another important argument:

1 Like
8

It’s not from March 2025, but the research is going on.

2 Likes
9

Yes, but I would like to emphasize footnote #9, particularily this quote:

3 Likes
10

There’s no such requirement in your link:

Qubes-certified hardware should run only open-source boot firmware (aka “the BIOS”), such as coreboot. The only exception is the use of (properly authenticated) CPU-vendor-provided blobs for silicon and memory initialization (see Intel FSP) as well as other internal operations (see Intel ME).

2 Likes
11

Are you saying you can get rid of the negative features of Intel IME by, temporarily using a particular Operating System for awhile? Going on to use Qubes? Without doing a hardware Flash, (meaning open the computer, attach wires from another device) and Flash the target computer?

What OS can accomplish this? How well is this tested by others?

1 Like
12

No, I mean overwriting the IME.
You can install the original IME back again when you want to, but I don’t advise doing this sort of thing again and again.
It will always be a hardware flash.

PCs these days have updaters, so they allow updating to these things over time.
So you just have to know how to write to these things and just do it.

BIOS updates… Write your own BIOS to flash to it, fixing all the issues.
IME Updates… Download Minix, add your IME code, flash.

The same goes for many parts of the computer.

If anyone allows firmware updates and flashing to their hardware, you just need to know what commands to send to what devices to allow the flashing and then to flash it.

This itself is a major security vulnerability in computers these days.

Which is one thing that many people will exploit.

Upload a custom IME to an Intel CPU, then you can watch and monitor everything that passes through the CPU.

Do this on the NIC, and you have a device sitting on someones network that you can freely access at any time as it will create a connection to your own server from inside the network. And if you have the BIOS flashed/updated with your spyware as well, you can wake the computer, then use the computer to do whatever you want.

This is one thing I love about Qubes.
Run everything separated in guests, and nothing that you do things on has direct hardware access. Meaning you need to boot to a mini system to update them if you ever want to. But that is the down side unfortunately. Protection prevents removing bugs and fixing security holes and flaws in your hardware.
So people can’t EASILY get access to the hardware without sending the signal from outside to directly interface with your NIC.

Often flashing is done with Windows, because of the insecurities inside Windows itself and the lack of restriction and security that is inherent in the operating system to allow all forms of bad things to happen. (Which is why there is more malware that works on Windows than anything else)

I don’t know how well it is tested by others. I was first doing this back in 2007 when I learned about it and what they actually put in the CPUs and the fact it was actually an operating system.

These days it would be more advanced, and they may have it completely custom, but it would still be similar methodology.

1 Like
13

The distinction between citation #3 and citations #1 and #2 is that citation #3 was about backdoor instructions in a CPU, rather than an additional processor acting as a spy (which is what Intel ME and AMD PSP are).

In addition, backdoor instructions in CPUs are indeed a thing. They are extremely difficult to find. Chris Domas shows the exhaustive work he did to find one in an x86 (although not an x86 by Intel nor by AMD) CPU.

When a firmware update provided by Lenovo or Dell is distributed to you the user, that firmware update software flashes more than just the closed source UEFI (which is usually based an something open source, like Tianocore in Dell’s case) but also flashes new Intel ME firmware.

The HAP bit can be rendered impotent in any of these firmware updates.

If I were “upstream” of Intel (who is upstream of ODM, who is upstream of OEM) in the decision making, I would have the HAP bit simply appear to work for the duration that the Intel ME can be observed. That entire stream is under NDAs that those bound by them will take to the grave (if they know what’s good for them and their families).

What Purism does is enforce the known-neutered Intel ME with the hardware chip on the Librem 14.

Perhaps this larger community could MITM the pins of the UEFI chips, maybe with another computer continuously in a production setting, to observe traffic during firmware updates, observe what happens during boot, detect and obstruct traffic undesirable to machine owner, and add cryptographic verification working on behalf of machine owner rather than “upstream” who is fundamentally an adversary.

There are some out there who have successfully run their own code on the processor of the Intel ME. Perhaps a modified Minix kernel or some other kernel could bluepill and write Intel’s official Intel ME modules to a USB device.

If the Intel ME isn’t loaded “correctly”, the workload CPU (Core i7, Xeon, or other) will stop working within 30 minutes. Whatever is transmitted from the Intel ME to the workload CPU to keep the workload CPU running would have to be included.

On a similar topic, one has to wonder what is entailed with a community effort to reverse engineer what happens between the workload CPU and a motherboard so that a working motherboard could be created without Intel’s NDAs and without the stupid criminal Intel ME.

2 Likes
14

Citation needed.

1 Like
15

On the page on Purism’s website titled Measuring the Intel Management Engine to Create a More Secure Computer:

With this solution, Heads will measure the BIOS and ME code at boot time, compare them with signatures stored in the TPM, and alert the user if that code has been tampered with. By doing so, the user is alerted to any attacks that have altered the ME or the BIOS in a persistent way—allowing the user to know the system needs to be considered “compromised” (or “untrusted”)

2 Likes
16

Define known-neutered Intel ME.

1 Like
17

I am not the best to ask. There are others who have more advanced working knowledge on the topic that should be asked. Some of these people might be at Positive Technologies and Purism.

The best definition we, “we” being the larger community and not one specific group/organization, as far as I know is:

  • the Intel ME is a known version where the HAP bit is not rendered non-functional.
  • the HAP bit is set
  • undesirable pieces of software “modules” are removed from the larger Intel ME blob
  • even better (but not always possible): the hardware is not amenable to the functionality of AMT and/or other software that does one or more things that AMT does.

The larger blob that is the Intel ME and individual blob pieces within the Intel ME are not very well reverse-engineered nor very well understood. Some may disagree with this, but nonetheless they are not as well understood as they could (let alone should) be.

There are “custom” software “modules” out there. Intel ME is something to be “developed on” for whatever “platform” an ODM/OEM are trying to build.

Without every single line of source code, or every piece of object code accounted for (now possible though probably not feasible with some Ghidra plugins), there is no robust and consistent way to verify that code within the Intel ME is not periodically looking for hints within the memory space of userland to execute whatever code suffixes that hint.

2 Likes
18

People typically differentiate between deleting, neutering/neutralizing, and disabling.

Deleting means you can fully delete ME, which only is possible on ancient systems.

Neutering/neutralizing means you delete as much of the ME ROM as possible, which also isn’t possible anymore, or at least isn’t possible with the method used by me_cleaner. It stopped working around the 8th generation of the Intel CPUs.

Disable means to use the HAP bit to shut down ME, this method is still working.

Any Intel system with a CPU newer than 8th generation is unlikely to be able to do more than disable ME using HAP.

You are also flat out wrong about ME not being reverse engineered, or well understand. Smart people have invested a lot of time in reversing ME, and development version of some version of ME have also been leaked. All in all, ME is a lot better understood, then you seem to think it is.

2 Likes
19

I agree with you that the Intel ME is well understood relative to what we had when Intel had just shat it out for us.

We still don’t have source code. We still don’t have any meaningful accounting of every piece of machine code in the blob.

A viable chunk of executable machine code that is suitable for normal everyday use, and NOT solely intended for mapping out the coprocessor and its connection to the CPU and everything else on the board, that can be compiled from source code both existing and available without Intel’s source code, does not exist today.

Dell and Lenovo are still releasing their turds (this year), instead of source code and documentation, for Intel 8th-gen chipsets.

If we could have a qualified professional audit every Intel ME blob shat out by OEMs like Dell and Lenovo within every larger turd they frequently release, we could state this with high confidence.

The performance of such audits is still effectively useless.

The coprocessor that Intel ME runs on has access to all memory used by the OS. Any “hint” that gets its way into memory, which can be done by visiting a web page, can inform whatever is running on that coprocessor to do anything the authors wrote in there.

1 Like
20

What we do have today is too little and far too far away from what could be considered close to satisfactory.

2 Likes