Librem 14's ME disabled but not neutralized

Dell XPS:

  • Does not have open source firmware (coreboot)
  • Does not have open source EC firmware (WIP for Librem 14)
  • Does not have privacy switches
  • Does not have an ethernet port
  • Has gaudy branding. Its not significant, but I prefer the quiet unbranded look of the librem 14 over a giant dell logo.
  • Forever bears the taint of microsoft on its keyboard

But they are very good laptops. until a couple weeks ago, my daily driver was the XPS-13 9350 developer edition and it was a wonderful laptop (donated to family, laptop still running great after 5 years) but I’d still take a librem 14 over the XPS line for the reasons above. Additionally a point I can’t claim factually because I haven’t tested it but: given purism’s goals of the least amount of runtime loaded firmware binaries, I expect the hardware in the laptop will be better supported in more esoteric operating systems. Won’t matter if you just plan to run linux because the XPS laptops have great support in linux, but I like to use some less popular operating systems.


This was a case of miscommunication internally where many of us (myself included and perhaps most significantly) didn’t know that the status of the ME changed with the Librem 14. I had thought the same process from the past could be and had been adapted in some form to the new CPU/ME. I was clearly mistaken.

I specifically removed “neutralized” last week from that page when I discovered I was mistaken in believing we would be able to perform the same neutralization in this new CPU as in past versions of ME. Somehow it didn’t go through so I just made the correction again and am generating the new pages now.

We aren’t compromising as much as we are facing the limits of the state of the art when you switch to a newer processor. I still very much want this new ME neutralized and due to various confusion (possibly completely on my side) I had thought the same approach that had worked in past processors would apply for the Librem 14. Otherwise I would have made sure we started looking into solutions for this earlier. Regardless, this is something I do want to look into now, but obviously it will take some time to find a solution.


Intel’s “state of the art” goes hand in hand with keeping NSA backdoors alive and well? What’s your opinion on such things?

Can you offer option for Librem 14 with older CPU but neutralized? For some of us, neutralized last CPU > non-neutralizid latest CPU.

I doubt we would be able to offer the Librem 14 with a many-generations-old CPU as an alternative, because among other reasons (including possibly requiring a redesign) I don’t know that there would be sufficient demand. Instead I’d much rather put that effort into neutralizing the new ME, which ideally would result in something we could use in the future.

We went through a similar process when we first released the Librem 13 and it took us some time to get to the same point with its ME. When we did, though, it was something existing customers could take advantage of with a standard firmware upgrade.


How confident are you that a supposedly disabled ME (but not neutralized) is actually disabled and cannot be surreptitiously enabled?

Worded differently, to what extent do you consider neutralization of the ME paranoia?

Ultimately the problem is that because the source code is closed, we cannot verify whether the HAP bit does what it says it does, so ones confidence in the disable feature comes down to how much trust one puts in Intel I suppose. It very well could disable things exactly how they say, and there is a possibility it doesn’t (a possibility that would require a direct conspiracy between Intel and NSA).

Since we can’t know for sure, we’ve additionally added the neutralization step on past Librem laptops so that even if it were somehow remotely enabled even with the HAP bit set, there isn’t much code left for it to execute. The NSA isn’t magic. Code, especially code to allow remote access like that, does take up actual space on a chip, so neutralization gives extra peace of mind.

Many of these concerns come down to the fear that someone could remotely control a machine using the ME. This concern originated in the fact that corporate ME releases ship with Active Management Technology (AMT) which lets an IT worker remotely manage a fleet of machines including seeing what is on their screens, as long as AMT was enabled and the machine was on the network.

We originally addressed these concerns by installing the consumer ME that doesn’t include AMT code at all. That way you know that code isn’t present to execute to begin with. Then you are just left with worrying that somehow the same remote access technology from AMT is included by default, in secret, in the base ME, but somehow doesn’t take up nearly the space that AMT does even though it provides the same features. It seems unlikely, but I suppose it could be possible.

There is value though in neutralization outside of the above peace of mind and outside of “paranoia” (and paranoia to me isn’t enough of a reason to drive most security decisions–some of the most convoluted, overengineered, overcomplicated, and ultimately less secure security measures I’ve seen have been driven by “paranoia” instead of actual threat modeling).

The value outside of peace of mind and “paranoia”, is simply that by reducing the amount of mystery code we have to rely on to a minimum, we reduce the overall attack surface, not just from some alleged NSA remote access exploit that is based on speculation of a conspiracy between the NSA and Intel, but also from actual ME exploits in the wild. So all this to say we find neutralization valuable and want to re-enable that protection for our modern CPUs when it’s possible.


where did you get this “information” from? A system with the ME disabled via the HAP bit cannot be re-enabled arbitrarily – it would require re-flashing the firmware. The same re-flash could restore a neutralized ME to a working one. Plus, there are additional protections done to prevent access to the ME from a booted system, such as disabling the PCI/HECI interface.


I could be wrong but maybe AMT only works over a built-in GbE controller anyway. So traditional Purism laptops, having no GbE at all, were less likely to be vulnerable to remote control exploits via AMT. (That’s not to say that it would be impossible for the ME to support AMT over some random ethernet controller or even over WiFi but the ME code doesn’t write itself and magically load itself into your computer, and there would be additional challenges.)

As far as I know, none of the Purism laptop CPUs, up to and including the Librem 14, officially have AMT support at all. So it would require a certain amount of misinformation from Intel (which, yes, could be part of some grand conspiracy :wink:).

Perhaps, as of some future Intel CPU, AMT will become mandatory and unavoidable … and it will be time to move away from Intel - for this and other reasons.

Going with Dell means you’ll never get ME neutralized.

Going with Purism likely means it’s only a matter of time before it is neutralized (not to mention all the other bits @craftkiller called out above).

1 Like

AMT only works with a built-in Intel-made GbE or Wifi. A Realtek GbE or Atheros Wifi like Purism uses wouldn’t be able to be utilized even if AMT were present/active (which it most certainly is not)


Hi Kyle, thanks for your explanation. I’m kinda new to this ME topic, and was wondering if it’s possible to neutralize it afterwards - once purism found out how?

He answered this in another thread: New Post: Librem 14 Update: Freed EC, Shipping Beginning in March

“When we accomplish that [neutralising ME] existing owners would just reflash their boot firmware (coreboot or PureBoot), which contains the ME code as part of it. In terms of the risk analysis, I talk about that a bit in a different thread .”

I think there is a risk of “bricking” your computer while doing so. This is why, personally, as a Unknowledgeable linux user, I’m juggling with the idea of waiting a bit before ordering it, giving time to purism to find a way to neutralize it themselve.

According to the need and interest in having it disabled and neutralized, I’m guessing it should be high priority in their “to do” list.

1 Like

I understand… thanks.
Good thing you’re waiting.
I already ordered, in September. I need it for my work but I also need it to be as secure as possible. Now I regret I bought the librem 14 instead of 15…

With uniform hardware, the risk of bricking devices during firmware updates is fairly minor. It mostly comes down to don’t power fail the device. Given that the laptops have an internal battery: make sure they are plugged into the wall and fully charged and you should be fine. Well, and don’t do it if the Earth is encountering a coronal mass ejection event, but those are fairly rare.

In the event that updating fails, the firmware chip is accessible, and can be reprogrammed by a chip programmer without desoldering it. You can likely do it yourself, if you have or can build (raspberry pi / arduino, maybe with a level shifter) a chip programmer. In the worst case, purism could reflash it for you (with the major downside of waiting on shipping and their turnaround time).


Yeah, the real risk of bricking comes when you are playing around with creating your own version of the firmware, or using firmware from untrusted sources.

1 Like

The other risk is applying the firmware for one model/version to another model/version. I think the firmware upgrade script tries to stop you doing that but …

Actually, the EC is the priority… better to have rgb than neutralization. I’m not happy with that since that’s not my priority nor the reason why i decided to buy a librem instead of other brand… security is my number one priority and rgb is completely accessories.

What about Librem Mini v1 (with Intel Core i7-8565U CPU) - it has disabled and neutralized or just disabled Intel ME?

Also, maybe will be safer to use AMD Ryzen processors instead of Intel processors? Or AMD processors also have backdoors?

AMD systems have a similar thing to the ME, it’s called the PSP. It’s worse than the ME in a way because we know almost nothing about what it does, at least with the ME we have some understanding of it.

Not quite true, in the last couple of years there was quite detailed dissection of psp. The problem with psp is just that it’s fully signed so you cannot tamper with it (eg neutralize) as it would change signature. But you can still read it for offline analysis and tamper with runtime.