How secure is System76 laptop with disabled Intel Management Engine compared to other mainstream laptops?

I believe that there are many instances in this community discussing whether Intel Management Engine should be disabled, for example:

However, today, I found out that System76 laptops have IME disabled as a security feature, Darter Pro for example:

Protect your data and privacy with a disabled Intel Management Engine alongside robust security features like encryption on setup — giving you peace of mind every time you open your laptop.

Does this mean that IME has been proven to be a security vulnerability (at least, by System76)?

Another issue worth mentioning is System76’s coreboot instead of Secure Boot. Many would argue that Secure Boot, especially with Linux OS, doesn’t matter much. But as a whole package, disabled IME + coreboot, is this combo the most secure setup people can get today?

1 Like

This is an issue that comes up quite a bit and yet there’s still no great answer from either side. People will make claims without backing them up or they’ll link you to unbearably long forum posts with scarce sourcing.

As you pointed out, the Privacy Guides team believes there’s no point in worrying about it. Elsewhere on the internet, some will say it’s a bad idea to disable IME and others will say it’s good. It’s not a great answer and I’m hoping the Privacy Guides team can eventually write an article to finally address this long unanswered question.

3 Likes

As I understand it,

It is “proven” to be a security vulnerability in the same sense that a door or a window in a wall is “proven” to be a security vulnerability.

It just simply, innately, inherently, is more of a risk to have ME/AMT than to not have it, in the same sense that it is simply more of a vulnerability to poke a hole in a concrete wall for a door and window, or to poke a hole in your firewall, the door or window or open port is not necessarily insecure but it is unarguably less secure than not having it present at all.

This is not the same as saying that there is malicious intent behind the feature, that it is exploited or easily exploitable in the wild, or that it is vulnerable to an unacceptable degree. I’m not weighing in on that. But it certainly offers more potentially exploitable surface area compared to not having it present.


FWIW, despite the above, I deliberately use ME/AMT in some situations, and have specifically sought out hardware with ME/AMT built-in. Based on my limited understanding of the pros/cons, I consider it an acceptable risk for my current needs. But maybe this is naive, idk.

3 Likes

Risk to security? Privacy? Proof? Threat model? What attacks have been conducted, hypothetical or actual? Does ME/AMT offer any security benefits despite the increased hardware attack surface? Let’s not treat unknown unknowns as leaning one way or another and offer blanket statements - I get it’s definitely and increased attack surface, but I actually don’t think it’s important for a p99 amount of users in my opinion.

For a non rhetorical question, what is a threat model + threat level to even begin to worry about these systems?

EDIT: I apologize if my quote seems to be pedantic, but I believe risk is context dependent


I would currently consider it fairly unlikely to be attacked in this manner by anyone other than advanced state actors.

However, the risk to all users if an an easily exploitable vulnerability is discovered in the future is extremely high, so it is still worth advocating against Intel ME.

4 Likes

No worries, and no need to apologize, I can be a pedant at times, language matters, preciseness matters, and I know I can be sloppy or unclear in my own language sometimes. I appreciate both the spirit of your comment, and some of the points you made within the context you made them, I just don’t feel they contradict what I intended to communicate.

Risk to security? Privacy? Proof? Threat model? What attacks have been conducted, hypothetical or actual?

I think we are answering overlapping but separate questions. Please reread my earlier comment with a fresh eye, because I feel you may have misinterpreted what I intended to say or are combining it with arguments from others/elsewhere that I haven’t made and don’t intend to make.

Risk to security?

Yes. I don’t believe I’ve encountered anyone who would argue otherwise. (there is lots of room to debate whether it’s a big risk or small risk, acceptable risk or not, or in what contexts it matters (and this ← is where I’d agree with you that interpreting that risk is very context dependent) but I’m unaware of anyone who argues there is no added risk to enabling ME/AMT.

It’s up to each of us to determine whether those risks are valid for our personal threat models, whether they are big or small, acceptable or not, and how we’d like to address known-unknowns and unknown-unknowns. But I think that it is fairly hard to argue there is zero added risk to enabling something that is essentially by design a backdoor [1] of sorts with its own networking capabilities independent from your OS. This is not an argument about its intent, its purpose, whether risk outweighs reward, etc, just simply that the mere existence of such a capability entails risk which should be acknowledged and accounted for.

I think the distance between our points of view stems from how we are interpreting the question. I believe you interpreted the question in practical terms (is ME/AMT a likely practical risk most people should be concerned about whereas I interpreted the question theoretically/logically (does a system with ME/AMT enabled introduce risks that a system without ME/AMT is not vulnerable to). Essentially we are addressing related but different questions, and both questions can be answered differently without any contradiction.

Let’s not treat unknown unknowns as leaning one way or another

I don’t think that I did, but since you brought it up, I do consider unknown-unknowns and known unknowns to be inherent risks. But that is probably a separate conversation.


  1. i’m using backdoor neutrally here, not implying maliciousness ↩︎

1 Like

This is also my suspicion - but reading some of the CVE again is quite crazy - remote code execution from Intel ME is wild. But I really do wonder how often that has been executed on for the target audience of System76…

BUT, let’s say Intel ME 0 days are almost always state actors, then it begs the question if System 76 w/ ME disabled is really up to such a threat model. At best, it’s improved threat model by reducing attack surface, but I suspect that most users are going to get pwned on their OS setup if long before they are needing to worry about Intel ME.

I’d suppose the analogy I can make is that this benefit of disabling Intel ME is like filling the crawl space of a home with concrete in case someone snuck in underground, but doesn’t guarantee anything if you’ve locked your front door. Analogy breaks if someone finds an easy exploit, but I do wonder the probability of such an exploit being super easy as to worry about.

For layman consumers with regards to hardware? Perhaps it’s solid, only short of using a CPU that never had Intel ME to begin with, but I don’t think I’m qualified to say if it’s good enough for more intense use cases. But how much this really matters depends on what you are defending against. Using a recommended secure Linux Distro with hard drive encryption will cover a lot of use cases.

If you like the idea of sensibly customizable hardware, easy to repair, and FOSS mostly down to the CPU, then yeah it’s interesting hardware and might be worth your time.

1 Like

I agree - both are important, and I’m glad both opinions are in this thread. I generally gear towards practically unless I’m threat modeling from the start.

1 Like

I believe that any out of the box security measure is good for anyone, regardless of the threat model, even though most layman consumers are most likely to fail on their secure setup elsewhere and everywhere :joy:

Therefore, the real question for me, considering all the factors and possibilities, is this setup, i.e. disabled IME + coreboot + open firmware + Pop!_OS - as it’s their intended setup and supported OS, actually more secure than other out of the box Intel IME + Secure Boot setup?

If it’s not more secure, it would be better to get something like Framework, Tuxedo, or any Ubuntu certified devices. If it’s actually more secure, sure, System76 would be the #1 option.

This is just not how security works, which makes your question difficult to answer.

The other problem is that there are hundreds+ of factors that go into UEFI/firmware security, and you are focusing on a single one. Maybe they are more secure than Framework in this one way, while being less secure in 10 other ways you’re not paying attention to.

I have not really seen an in-depth analysis of System76’s security, nor anyone else’s like Framework’s, etc.

It does seem likely to me that disabling Intel ME and coreboot does make System76’s laptop more secure purely based on the reduced attack surface, which is always a good thing. Like I said, I have nothing else to base this assumption off of though.

2 Likes

Can’t quite recommend this. System76’s hardware does not have the best of secureboot implementation an is only there to alllow Windows to pass as per firmware-open/docs/uefi.md at 3e19b73397c27cf88b048902a3f080f584d0f851 · system76/firmware-open · GitHub

Note that the Secure Boot support present is only intended for allowing Microsoft Windows installation checks to pass. It should not be relied on for system security due to limitations of the implementation.

Depending on what you actually want to do, but basically no, because the Google Pixel with GrapheneOS and desktop mode exists. I won’t re-litigate this one, though.

1 Like

Are these things mutually exclusive? Or do they need to be evaluated all as one entity? If it’s the latter, it’s a bit trickier of a question, otherwise it’s quite easy to check if each feature is one that works for you.

Agree. But for typical users, can’t we compare both setup as an overall security model despite pros and cons? Like every gadget reviews out there, for example. Sure, there’s no definitive answer, but there should be a champion (best one overall considered all the factors).


@AmyIsCoolz I know that System76 is not a good contender for Windows. But what about its security when using with Pop! _OS, or other supported Linux distros?


Does the desktop mode exist currently in GOS? The last time I checked, it’s planned for Android 15, but was removed after the beta. AFAIK, only Samsung DeX and Lenovo/Moto have desktop mode in Android world. And even with that (I use them both), it’s far from what GNOME has to offer, also the apps ecosystem. I have never tried Cosmic, though.


It’s the latter. The thing is I want a new laptop, can’t decide between System76 and Framework.

Framework for it’s ability to upgrade (even the board) when needed. It also officially supported Fedora. This is important because I use Podman a lot. Any Ubuntu-base would mean headache.

But System76 with its advertised security feature seems promising. I have no idea, though, hence the question. System76 with other Linux support (other than Pop!_OS and Ubuntu) seems lacking, for example, on their Fedora repo about firmware compatibility issue with Fedora’s regular kernel upgrade, and the hassle when upgrading to the next major version.

Not a firmware/hardware engineer, researcher or enthusiast but from what I have skimmed, it is a bit more complicated than that.

What does this process involve? Are Intel CSME controlled security-features still available? fwupd’s Host Security ID plugin details some features that are useful for firmware security. Depending on the platform, several of those will be dependent on CSME (firmware-based TPM 2.0, memory encryption, hardware-backed secure boot and so on). Even vendors like Apple (Intel powered Macs) and Google (Chrome devices) despite taking steps to minimise Intel CSME (1, 2) do not ‘disable’ it, and sometimes make/made use of security features provided.

Most likely. The UEFI/BIOS implementations from Independent BIOS Vendors (IBVs) like AMI, Insyde and Phoenix are widely criticised and poorly regarded by firmware security engineers and researchers. Coreboot implementation is usually regarded as a step up in quality, provided the vendor can also follow through by implementing all the firmware security features needed on top (as is the case with Google’s coreboot for ChromeOS devices and their coreboot for the Android Pixel C tablet).

What is the context, consumer laptops? As I have heard, the current gold standard for hardware and firmware security in a consumer laptop is a recent Apple Silicon Macbook.

2 Likes

Having an insecure implementation of secure boot is bad for both Linux and Windows

1 Like

Yes, desktop mode exists and can be enabled on later Pixel models. There are a lot of threads on setting it up over on the GOS forums. The UI is inconsistent across apps. Some work well and others struggle. I prefer to have my main desktop monitor in portrait mode and this is not possible with my p8 connected via an HDMI port. I suspect it will reach a state of reasonable convergence eventually and you could carry one device if it suited your needs. One advantage to desktop mode is you can run a few apps side-by-side horizontally.

I’ll add that the Pixel Tablet can be used more easily as a computer replacement than desktop mode on my p8. I like using it in portrait mode. I have the standard Google case which allows easy vertical arrangement. Bluetooth keyboard and mouse work well most of the time. Some apps don’t like the presence of an external keyboard. I’m still figuring out which ones and why. I use it for work access via Citrix as well as work apks. They are in Private Space with a Mullvad VPN running from an IP that the work servers will like. The work apps are faster with ethernet to usbc LAN which is nice because Citrix is slow and lame most of the time. I have a stand which makes this setup more ergonomic by raising the tablet up a foot or more off the table. If desired you can use it with a wired mouse and keyboard plugged into a usb peripheral dock.