Please do not get me wrong, I don’t complain here about what I’m asking! I just want to know if something has happened on the topic!
AFIK there’s no breakthrough after now nearly three years when it comes to neutralization of the IME firmware on the Librem 14. And we can’t be sure that setting the HAP bit to disable the IME is working. I’ve read this information on forum threads and FAQs that were created years ago.
Now nothing has changed and I have to confess that I don’t understand a lot about the engineering of this firmware. But are there any news regarding the IME on the Librem 14 and if it only was that it’s impossible to neutralize due to a digital signature checking of the CPU of the code that is running on the IME?
To me it feels like Intel has worked very hard so that it’s a lot harder to find a way to run a computer with neutralized IME otherwise there would have been progress on the topic.
Edit: Another question that came to my mind is whether there’s any other non free firmware/software running on the Librem 14 because AFAIK there shouldn’t be?
Because there were no updates in the last two years.
Sorry if I named it wrong, but yes! I’m talking about the Intel Management Engine. It should be named Intel Management Engine Interface, therefore IMEI?
Except that IMEI is International Mobile Equipment Identity. So such a usage would be unhelpful. (Yeah, OK, your typical Librem 5 will have an IMEI and your typical Librem 14 will not have an IMEI but …)
We can, you can check even from Linux that the ME is dysfunctional - it will not show up on PCIe. Also if you look at the Coreboot memory logs (cbmem) then you will find error messages from Coreboot while it tries to query the ME and status.
So as far as what we can test and observer the ME is disabled, yet its firmware is indeed there and I am afraid there has not been any progress for 10th gen and onward for removing the ME firmware, what was called “neutralization”. One of the problems here is that a lot of the firmware structure is unknown so you can not be sure what is stored where and how these things interconnect. But the bigger problem is that many parts these days are also used for proper operation, at least initialization. So you can not just toss out arbitrary parts of the firmware, it will break the function of your device.
So IMHO the only way to go forward is to use the HAP to disable the ME at runtime (i.e. when the OS boots) and try to make sure we have tests to verify that it is actually disabled.
Thank you Nicole, so I was wrong on the verification of the HAP bit. This gives me a piece of mind on my Librem 14!
But nonetheless you confirmed that it’s not any longer possible to neutralize the ME. And it’s very unlikely that it will be possible at least it feels like this after such a long amount of time. It’s very likely that Intel works against neutralization of the ME firmware. What you wrote looks to me like Intel has changed the binary structure of the ME firmware on purpose so hard…
The only scenario that I’m afraid of without a neutralized ME firmware is that an attacker would send a specific packet sequence to the computer, enabling the functionality of the ME and use it as the backdoor that it was meant to be.
Nicole is there any other closed source firmware running on the Librem 14? Like the CPU microcode and other firmware parts that are needed?
Well, I don’t necessarily see it that way. The effect is as you describe it but I don’t think they do this on purpose. See, the ME has legitimate use cases, especially for remote management of large installations which would otherwise become a total pain (think of really large corporations, you can not really ask either the admin team to run around all day fixing broken installations etc. or ask the users to return their computers to the IT department for service). Since the ME needs to have deep access to the system to provide that functionality it needs to be made secure against tempering - clearly. And this is what, I think, Intel is simply trying to do here. this is not an attempt targeted at developers trying to neutralize the ME but more against malicious attackers - effectively of course both get hit by it.
Since the ME is implemented in a small subsystem of its own, a small operating system running on it etc., it makes kind of sense to also use it for more functions than just remote administration. and that’s what Intel is doing, they put more and more system management functions into the ME which assist the BIOS and operating system eventually also abstracting away nasty low level stuff for power management etc.
So what I am trying to say here is that I do not think that Intel (or AMD with its PSP which is effectively the same thing) is trying to purposefully hurting free software development or purposefully trying to introduce backdoors.
BUT the methods used of course can and should be debated. Security by obscurity has never been a good strategy nor has security by keeping secrets (private keys) proven to be a successful strategy either. So we have all rights to demand from Intel to be more open about the ME, to make disablement a documented feature, to help the community to develop tools to verify actual disablement, to develop tools to control the ME etc.
Because even if Intel (or AMD) have no malicious intent with the ME/PSP we still are in jeopardy that someone else might take advantage of the implementation details that we have no insight into or control over.
So we will continue to carefully watch the situation and we will also support, as good as we can, efforts to reduce the attack surface as much as possible.
And finally concerning “packets sent to re-enable ME” - as far as we can tell this is simply not possible. From what we can the community can tell if the HAP bit is set the ME is not running anymore so it also can not accept any data traffic from anywhere to enable more parts of it anymore. Of course since all this is a black box we can not be 100% sure but I would say 99%. Second, assuming such a packet could only come over some network interface we can be pretty sure that WiFi can be excluded as attack surface since Purism does not use the “vPro” ready WiFi cards that are made for this. On the Ethernet side this might theoretically be possible but given what we know from disablement using the HAP bit I would say chances are really low that this can be pulled off somehow.
Doesn’t it also depend on whether you are using the built-in ethernet or a separate, dedicated ethernet?
And other countries will no doubt point out that even if Intel/AMD have no malicious intent and even if there aren’t any unintentional vulnerabilities … Intel/AMD could be directed by the US government.
We know that there are (seemingly) unintentional vulnerabilities but we can only hope that that situation improves over time. By definition Intel is ensuring that it is difficult for security researchers to uncover those vulnerabilities, a different kind of security by obscurity.
I’m a bit sceptical as to how successful that is going to be (when used nefariously). Most likely the sender would have to be on the internal network i.e. the intended use case for remote management (even if used in concert with a VPN).
From outside the internal network by a malicious party, it’s going to have to get through the firewall or it would have to be used in a blended attack where one internal system is compromised first, using a different attack, and then that system is used as a launching pad to activate all the IMEs.
Of course, my scepticism doesn’t count for much. We know that there are lots of malicious parties who are swarming all over systems and software looking for vulnerabilities.
Hi Nicole, can you please advise if there are any “tests to verify that it is actually disabled” that we can run?
Is it just seeing that the ME is absent from PCIe and checking the cbmem logs, or something else?
if the HAP bit is set the ME is not running anymore so it also can not accept any data traffic from anywhere
Can we be 100% certain that it is not running though? Could it not be quietly and invisibly sniffing data passing through the Ethernet interface with one semi-open eye only, and be woken up when a certain sequence of bytes passes by?
