The Linux world is currently seeing an explosion in new users, thanks in large part to Microsoft turning its Windows operating system into the most intrusive piece of spyware in modern computing. For those who value privacy and security, Linux has long been the safe haven where there’s reasonable certainty that the operating system itself isn’t harvesting user data or otherwise snooping where it shouldn’t be. Yet even after solving the OS problem, a deeper issue remains: the hardware itself. Since around 2008, virtually every Intel and AMD processor has included coprocessors running closed-source code known as the Intel Management Engine (IME) or AMD Platform Security Processor (PSP).
These components operate entirely outside the user’s and operating system’s control. They are given privileged access to memory, storage, and networking and can retain that access even when the CPU is not running, creating systemic vulnerabilities that cannot be fully mitigated by software alone. One practical approach to minimizing exposure to opaque management subsystems like the IME or PSP is to use platforms that do not use x86 hardware in the first place. Perhaps surprisingly, the ARM-based Apple M1 and M2 computers offer a compelling option, providing a more constrained and clearly defined trust model for Linux users who prioritize privacy and security.
Before getting into why Apple Silicon can be appealing for those with this concern, we first need to address the elephant in the room: Apple’s proprietary, closed-source operating system. Luckily, the Asahi Linux project has done most of the heavy lifting for those with certain Apple Silicon machines who want to go more open-source. In fact, Asahi is one of the easiest Linux installs to perform today even when compared to beginner-friendly distributions like Mint or Fedora, provided you are using fully supported M1 or M2 machines rather than attempting an install on newer, less-supported models. The installer runs as a script within macOS, eliminating the need to image a USB stick. Once the script is executed, the user simply follows the prompts, restarts the computer, and boots into the new Linux environment. Privacy-conscious users may also want to take a few optional steps, such as verifying the Asahi checksum and encrypting the installation with LUKS but these steps are not too challenging for experienced users.
Black Boxes
Changing the operating system on modern computers is the easy part, though. The hard part is determining exactly how much trust should be placed in the underlying hardware and firmware of any given system, and then deciding what to do to make improvements. This is where Apple Silicon starts to make a compelling case compared to modern x86 machines. Rather than consolidating a wide range of low-level functionality into a highly privileged black box like the IME or PSP, Apple splits these responsibilities more narrowly, with components like the Secure Enclave focusing on specific security functions instead of being given broad system access.
Like many modern systems, Apple computers include a dedicated security coprocessor alongside the main CPU, known as the Secure Enclave Processor (SEP). It runs a minimal, hardened operating system called sepOS and is isolated from the rest of the system. Its primary roles include securely storing encryption keys, handling sensitive authentication data, and performing cryptographic operations. This separation helps ensure that even if the main operating system is compromised, secrets managed by the SEP remain protected.
The Chain of Trust
To boot an Apple Silicon computer, a “chain of trust” is followed in a series of steps, each of which verifies the previous step. This is outlined in more detail in Apple’s documentation, but starts with an immutable boot ROM embedded in the system-on-chip during manufacturing. It first verifies early boot stages, including the low-level bootloader and iBoot, which in turn authenticate and verify the operating system kernel and system image before completing the boot process. If any of these verification steps fail, the system halts booting to prevent unauthorized or compromised code from executing.
Perhaps obvious at this point is that Apple doesn’t sign Asahi Linux images. But rather than allowing unrestricted execution like many PCs, or fully locking down the device like a smartphone, Apple’s approach takes a middle way. They rely on another critical piece of “security hardware” required to authorize that third-party OS: a human user. The Asahi Linux documentation discusses this in depth, but Apple’s secure boot system allows the owner of the computer to explicitly authorize additional operating systems by creating a custom boot policy within the user-approved trust chain. In practice, this means that the integrity of the boot process is still enforced, but the user ultimately decides what is trusted. If a boot component is modified outside of this trust chain, the system will refuse to execute it. In contrast to this system, where secure boot is enforced by default and only relaxed through explicit user action, x86 systems can treat these protections as optional. A motivated x86 user can achieve a comparable level of security, but they must assemble and maintain it themselves, as well as figure it out in the first place.
Reducing the Attack Surface
The limited scope of Apple’s Secure Enclave gives it a much smaller attack surface compared to something like the Intel Management Engine. As mentioned before, the IME combines a wider range of functionality, including features designed for low-level remote system management. This broader scope increases its complexity and, by extension, its attack surface which has led to several high-profile vulnerabilities. Apple’s Secure Enclave, by contrast, is designed with a much narrower focus. That’s not to say it’s a perfect, invulnerable system since it’s also a closed-source black box, but its limited responsibilities inherently reduce that attack surface.
It’s also worth mentioning that there are a few other options for those who insist on x86 hardware or who refuse to trust Apple even in the most minimal amount, but who still consider the IME and its equivalents as unacceptable security risks. Some hardware manufacturers like NovaCustom and even Dell have given users the option of disabling the IME (although this doesn’t remove it entirely), and some eight and ninth generation Intel machines can have their management engines partially disabled by the user as well. In fact these are the computers that my own servers are based on for this reason alone. Going even further, it is possible to get a 2018-era Thinkpad to run the open-source libreboot firmware. However, libreboot installations can become extremely cumbersome, and even then you’ll be left with a computer that lacks the performance-per-watt and GPU capabilities of even the lowest-tier M1 machines. In my opinion, this compromise of placing a kernel of trust in Apple is the lesser evil for most people in most situations, at least until libreboot is able to support more modern machines and/or until the libreboot installation process is able to be streamlined.
I’ll also note here that Apple is far from a perfect company. Their walled garden approach is inherently anti-consumer, and they’ve rightly taken some criticism for inflating hardware costs, deliberately making their computers difficult to repair, enforcing arbitrary divisions between different classes of products to encourage users to buy more devices, and maintaining a monopolistic and increasingly toxic app store.
But buying an M1 or M2 machine on the used market won’t directly give Apple any money, and beyond running the Asahi installer script doesn’t require interacting with any Apple software or their ecosystem in any way, beyond the initial installation. I’ve argued in the past that older Apple computers make excellent Linux machines for these reasons as well, and since the M1 and M2 machines eliminate the IME risk of these older computers they’re an even better proposition, even without considering the massive performance gains possible.
Ultimately, though, the best choice of hardware depends on one’s threat model and priorities. If the goal is to minimize exposure to IME/PSP-level risks while retaining semi-modern performance, an M1/M2 Mac with Asahi Linux is one of the best options available today. But if fully open hardware is non-negotiable, you’ll need to accept older or less powerful machines… for now.
Is Claude correct here?
What if I don’t trust Intel’s IME? I know this would not get rid of it but if I installed a network card that is not built in to the motherboard and used that instead of the built in one would that at least keep the IME off the network?10:15 AM
This is a reasonable mitigation strategy, and you’re right that it wouldn’t eliminate the IME — but let’s break down whether it actually helps:
How Intel ME uses the network
The Intel Management Engine has its own dedicated network stack that operates below the OS. On most consumer/desktop motherboards, IME shares the physical NIC with the OS using a feature called Intel AMT (Active Management Technology). The IME intercepts packets at the hardware level before they ever reach your OS.
Would a discrete PCIe/USB NIC help?
Mostly yes, with important caveats:
On consumer/desktop boards, the IME’s network access is typically tied specifically to the integrated Intel NIC. If you disable or simply don’t use the onboard NIC (and ideally disable it in BIOS), a discrete card from a different vendor (Realtek, Broadcom, etc.) would not be accessible to the IME. This is a legitimate and commonly recommended mitigation.
On workstation/server boards with full AMT, the IME can be more deeply integrated and may have more persistent access, but even here, the discrete NIC should be out of its reach.
Things to do to strengthen this mitigation:
Disable the onboard NIC in BIOS/UEFI — don’t just leave it unused; disable it entirely so it can’t get a DHCP lease or any network path.
Choose a non-Intel discrete NIC — a Realtek or Broadcom card has no IME hooks.
Disable AMT/vPro in BIOS if the option exists — many consumer boards expose this.
Consider me_cleaner — a tool that can neuter much of the IME firmware without fully bricking the system. It reduces the IME to a minimal “bring-up” role and disables its network stack and most of its features at the firmware level. This is the most thorough software-side mitigation short of buying hardware with IME disabled (like some Purism or System76 machines).
The honest bottom line
Your instinct is sound. Disabling the onboard NIC in BIOS and routing all traffic through a discrete third-party card is a real, practical mitigation that would deny IME network access in the vast majority of consumer setups. It’s not paranoia — it’s a reasonable thing to do if you don’t trust out-of-band management firmware running at a privilege level your OS can’t inspect.
If you have a question to ask, do so based off your own understanding and not the lazy parroting of whatever source you’ve manage to dredge up.
Boo
Ok. Since you weren’t mentally capable of parsing the question from the very top of the text…
Does using a Nic on a card defeat the IME’s ability to talk to the network thus preventing it from phoning home with my data or receiving nefarious commands?
Meanwhile, if anyone else is curious what AI says about that… please take it with the large helping of salt that such sources deserve, here it is. Threeve did not want you to have it.
Threeve isn’t the problem here. Your follow up comment’s middle section was succinct, quickly parsed, and didn’t offload the work of deciding what part of it was important to you onto the audience like the initial comment did.
IMO, if one is going to ask if an LLM’s data dump is valid, the polite thing might be to insert comments showing that the commenter has put in some work trying to make sense of it prior to posting.
Looks like you are not mentally capable to understand that nobody is interested in random verbose copy pasted AI output?
Just try to ask Claude this: Is it polite to copy paste huge answer from AI chatbot to public forum and just prefix it with “Is Claude correct here?”
ChatGPT said – Short answer: it’s usually not considered very polite, and in some communities it can be seen as low-effort or even spammy.
Nobody wants to read a giant verbose spew of text from an AI, even if it is “correct”, which in this case, basic googling or other research should have told you that it is largely not.
(and on top of that, why should any of us have to justify our statements or cite sources if the AI can’t be bothered?)
Ahh, so it has come to this …
Efficiency + Literacy != Humanity
Yes, I have been doing that for years so that I can use cheap intel gear for firewall/router boxes, probably even mentioned the add in NIC idea here myself back before we got the glorious calculators that do semantic searches for us and write it up so well. BTW if anyone dumps on you for using AI to share useful information, just ignore them like you would any other obvious fool.
BOT
Knock it off.
Man this is taking the thread from the recent Android coverage and running it to its logical end. Just a bunch of hypothetical ‘what if’ replacing any consideration of genuine reality. Perhaps of interest to hackers, but the antithesis of hacking itself. (hacking is always grounded in the extant)
doesn’t Apple have the same type of security chip running closed source with full memory access running on an elevated level on an independent processor? What’s the point on switching to mac? This is a sublimal apple advertisement, nothing else…
Nope. Apple’s approach is fundamentally different, and this article doesn’t even really touch on it.
This article explains a bit more of the approach, and why even Apple can’t disable the on-screen camera indicator on an Neo.
https://daringfireball.net/2026/03/apple_enclaves_neo_camera_indicator
If handed a FISA court order with gagging, could Apple produce a similar solution to that which is currently provided by Intel and AMD.
I know as a newspaper consumer about FISA courts of course, but it stretches believability that a court order can require work. Information, yes. Cooperation yes sort of. Mandating work? Constitutional problem with involuntary servitude. But stranger things happen all the time, sadly.
Could Apple engineer a solution in theory? Sure. But not in practice.
A FISA order is like a warrant in that it targets specific people for certain kinds of intelligence collection.
Compelling an ISP to attach a tap to a router is one thing. Developing a crack for the security on any Apple Silicon computer at any time for any reason altogether something else. That would almost certainly lead to an appeal back to the FISA court.
Not sure how camera relates to what Klaus said, but having an indicator, that is not directly coupled to the camera power rail, might be desirable in a product team kinda thinking.
It allows to be used the camera as a brightness sensor, without flickering the “recording” led.
Saving space and a few cents, still keeping everyone uncomfortable.
they implement somthing in silicon just not to have HW cover over camera ? :D what hell are we living in? oh btw peace of tape fix this :)
When Lenovo had the camera slider builtin, I thought: “There is zero trust left in software”
Only solutions that can be trusted are the ones users can physically verify.
Just need the same for microphones, GPS receivers and probably contact list… lol
There are one line commands for macOS which when run, nestle themselves deep inside of the OS including privilege escalation. Then they log everything you’ve done or typed and quietly delete themselves.
I learned this the hard way when downloading infected cracked software by accident once. The beauty is that they’re almost always written in AppleScript and thus don’t need compilation. I’ve analysed one of these scripts and they’re pretty clever and have multiple layers to them.
What I want to say with this is that macOS is hardly flawless, not that this article is claiming that, but privilege escalation? No thanks.
The question is if installing Linux wipes out macOS. If it does, and the wipe can be initiated without connecting to a network, such as with a USB device or a command typed into the console.
At some point you just have to trust a mega corporation, a class of entities that by and large have historically shown themselves untrustworthy, whether due to greed, malice, carelessness or naivete.
Whether or not RISC is a potential solution is also up for debate.
Would it theoretically be possible to make software hardened intrinsically and executed in the cloud, using machinery old enough to be completely ME disabled (EG Core2 Duo), or minimally performant at the requisite encryption and decryption needed for remote access (EG RISC)?
Valve seems to be the only system integrator that would sanction an open system because their business model doesn’t have a reason for this kind of security. Since they presumably ask AMD directly for the Firmware and AFAIK don’t need the system management to access network or memory perhaps they can ask for it to be disabled.
“The question is if installing Linux wipes out macOS. If it does, and the wipe can be initiated without connecting to a network, such as with a USB device or a command typed into the console.”
Asahi Linux installation does not wipe out macOS. It needs macOS to run firmware updates and initialize device firmware components. The device cannot be considered fully trustworthy while macOS or its firmware‑initialization components remain present on the disk or in the system firmware. Which is a showstopper, considering the size of the macOS system partition and how expensive Apple’s soldered-on SSD is.
There’s also the Talos workstations from Raptor Computing, but at an eye-watering price point, and the POWER9 CPUs they offer are getting rather long in the tooth. An M1 MacBook is a lot cheaper and more practical for most people.
I was really excited when they announced some years back they’d be partnering with a fab to produce an OpenPower chip for the next generation of Raptor products (and presumably whoever else wanted to use it)– but, alas, nothing seems to have come of it.
Unfortunately it seems like the wind has been let out of Asahi’s sails recently. They haven’t been able to keep up with all the changes Apple has been making to their latest chip iterations. They’re stuck on the M1/M2 while Apple is on to the M5.
I’m not entirely sure that’s true, when the project was restructured after the departure of the original lead they made the conscious effort to focus on upstreaming changes to the main linux kernel instead of maintaining an ever growing patch set to chase the latest silicon, an effort which by all metrics has been very successful. They’ve also got one of the most requested features (usb C display support) semi functional and M3 bringup is in progress right now. They’re still working very hard on things. Reverse engineering an undocumented platform is not a trivial task
Why is this not an option? Search: Deepcomputing RISCV
Worth considering the RiskV and more direct Arm options too – IMO usually better option than Apple as I’m not aware of any that have any elevated hardware privilege coprocessors, though I’m also not aware of any in that same M1/2 decent but not crazy performance level – you have Pi like SBC that are probably a little anemic for many users, or the giant Arm workstations, that are in most ways going to crush the M1/2 silicon.
Libreboot exists!
The most secure general purpose consumer computer in the world is a Chromebook. And it is 99% open source and if you wish you can use ChromiumOS which is 100% open source. ME is disabled on Chromebooks.
I believe x86 chromebooks still have ME, albeit stripped down to just the features required to initialize the CPU.
There just is no secure computer. Anything can be stolen, hacked, tracked, hit by a stray meteor, etc. it’s just a question of what risk someone is willing to accept for the things they want to do.
I rate this article an 8/10 in logic gymnastics to supplant a supplemented narrative.
I rate the above comment 5/5 for unsubstantiated buzzwords.
There are qualcomm snappdragon baset notebooks, you don’t have to deal with undocumented apple silicon.