There are speculative topics that appear on this forum such as IME. Many of us that don’t work in technical fields encounter the vast material on IME and cannot, on our own, find (or understand) evidence to rule out IME (and other “hardware backdoors”) or to reasonably disregard them. Much of the material appears quite technical such as talks at DEFCON on IME or by Joanna Rutkoska at Blackhat on not trusting hardware (see below for examples of talks intimidating to the layperson RE IME).
IMO, often, when hardware backdoors are raised as a subject here, there are counterposts citing “FUD” or something like “I can’t believe it took this long for the IME to be mentioned in this thread” but little actual evidence is provided for a lay person to feel reassured about the IME.
I think the vast majority of us that bring up IME are not trying to troll but really want to know why it should be disregarded. We are seeking guidance.
Would the mods and others here (with technical training and more advanced knowledge) please, please, please consider creating an official page in the guide that settles this (once and for all, if possible) for those that come here which are non-technical? Please lay out the rationale and evidence for accepting the presence of IME and other possible “backdoors” such as AMD PSP or ARM Trustzone. Please indicate which threat model levels should be concerned about something like this and which should not. This would be a great service to many of us.
Creating such a guide may help improve mod concerns RE bad faith arguments being posted on PG as it would create a knowledgebase baseline to promote good faith statements on IME out of the gate.
The shortest possible answer to this question for people who only like to skim a single sentence is that you should not concern yourself with Intel ME at all.
These posts themselves are a good example of the type of thing we are going to have to monitor much more closely going forward. You’re right that non-experts dismissing questions and posts as “FUD” simply because they don’t understand the question or aren’t personally concerned with the answer themselves does not facilitate constructive conversation.
What people consistently fail to realize is that the following two things can be true simultaneously:
Intel ME is bad
You should not disable Intel ME
The short-ish answer to your question is that you should not just “accept” Intel ME, AMD PSP, and mechanisms like them as a necessity, in the sense that you should demand change and seek out alternative products that do the same thing in a more secure manner. Intel ME has numerous and very well documented drawbacks and vulnerabilities. There is no reason that the security advantages that Intel ME does provide have to be part of an overall insecurely-implemented package. Intel could easily modularize these security components and implement them in a less lazy way, like Apple is doing with Apple Silicon for example.
However, you also should not go out of your way to modify an Intel or AMD product yourself with tools like “me_cleaner” that pose hugely significant security problems themselves. The risks of doing so far, far outweigh the risks that ME/PSP present to you. You are not a hardware security expert, and so you are not capable of effectively securing your hardware more than it is designed to be secure.
“You should not disable Intel ME”
" There is no reason that the security advantages that Intel ME does provide have to be part of an overall insecurely-implemented package"
" you also should not go out of your way to modify an Intel or AMD product yourself with tools like “me_cleaner” that pose hugely significant security problems themselves. The risks of doing so far, far outweigh the risks that ME/PSP present to you."
Why, though, do you say these things? You are making assertions as if they are second nature to you (which they may be as you are likely technically proficient in this subject matter).
For next-level layman education, would you please provide some links, resources, documents (or whatever it was) that led you to conclude these things? What is the evidence?
Well this is something that will be covered in actual detail when we write a KB article or post about this topic, I’m just saying what is the case for people who encounter this post in the meantime and have immediate concerns.
The topic seems to be controversial precisely because the kind of people who frequent this forum, and “privacy people” generally, fall into the false dichotomy of thinking that if something is a vulnerability we must defend ourselves against it at all costs. If a technical vulnerability is demonstrated in a product that many people use, no matter how rare or theoretical it is, people need to rid themselves of it even if it ends up causing them more harm in the long run. Imagine the headline “All your devices are insecure, but don’t worry you’re probably fine”.
Just imagine how anxious people would get if they knew how many vulnerabilities there really are in all of the apps, devices and protocols they use on a daily basis.
Also it reminds me of the spectre mitigations. The consensus seems to be to avoid enabling those mitigations because of the performance impact and the minimal benefit.
I’m in agreement that there should be an accessible article that demonstrates the issue, with references for people who are interested.
And we saw that play out to a degree with Yubikeys and all the fearmongering around that. Like newsflash, by the time the equipment to actually do the attack is commodity/cheap, the vulnerable yubikeys will be long gone and replaced (and that’s ignoring any other mitigations).
Yeah people are dismissive of the whole “muh IME!”, but it’s precisely because of the attitudes you’ve touched on, having to rehash “no, you won’t get pwned/spied on/anal probed because of ME.” a billion times.
You mention disabling IME using me_cleaner would introduce more issues, but what if you disabled it using the HAP bit instead?
@dngraycommented in another thread that no one fully understands what the HAP bit does but that it might affect things like Boot Guard. I still have a couple thoughts/questions.
Why would the U.S. government require the ability to disable IME for their High Assurance Program if it worsened rather than improved security? Not saying that disproves anything but something doesn’t add up right.
If disabling IME with the HAP bit ruins things like Boot Guard, would that negatively affect Qubes OS machines that can’t use secure boot anyways? If not, couldn’t disabling IME in those specific cases be beneficial?
If you read through that entire thread you linked instead of just @dngray’s last comment, I think you will find that I have already given my thoughts on these questions. I’m not sure what else I can add to the conversation, but if you find anything missing from my explanation I’m happy to clarify.
