This points directly to the answer to the original question: peopleās threat model do vary and the Qubes OS team decides to support folks whose threat models either donāt include Intel ME, or accomodate mitigations like AEM. (That doesnāt prevent them from also supporting folks whose threat mode does include those!)
Folks often forget to mention the threat model that constitutes the context of any question, and given how often that results in heated (and mostly sterile) discussions, I think we should remind more often that there is no such thing as āright or wrongā in security without a context.
One way to identify that context is threat modelling, that is identifying what you need to protect, from whom, and what are the consequences if you fail / how much convenience you are ready to loose to achieve that goal.
If you prefer desktop you have two decent options that I have seen
You could use the MSI PRO Z690-A (DDR4/DDR5) which is a motherboard with an open source bios that supports intel 12th gen. All you have to do is follow the guide on their wiki and plug in a USB to flash your bios. No external tools are needed for flashing like flashing thinkpads. Inside the bios options there is an option to disable intelās management engine using soft disable, or HAP bit.
Another option is to use the ASRock Z370/Z390 Taichi which can be disabled through a special method on that motherboard. I havenāt experimented with this one.
Neither of these will give you the level of freedom that older hardware will. Intelās core 2 duos donāt have it at all, up to ivy bridge (3rd gen) you will be able to remove a decent amount of code from the bios effectively removing it using me_cleaner, but past that it is not as effective.
If you donāt want the Intel ME or AMD variant, just disable them, and overwrite them.
To do this, just download the updaters for them, then insert your own image into the updater. Done.
Thatās what I did. Works like a charm.
Just BE WAREā¦ Donāt do it unless you know what you are doing.
Another option is to just disable it physically on the chip. Just cut the power line to the IME or variant.
That permanently disables it.
I overwrote mine with a custom variation so I have removed the ābackdoorā.
No, they donāt. LOL. You already knew the sky was blue before you ever ran into that wikipedia page, and you had a solid understanding of how time works long before you ever questioned why it exists. Itās nice to know why the sky is blue, but it was never a necessity to know that it is blue.
If you know itās a problem then I guess we just disagree about how to best convey the information to the newly initiated. I believe this backdoor stuff can be the line between life and death for many, and it should be treated as such. I think itās better for OP to get freaked out and walk out of here thinking the government is watching everything he does and then find out itās an unproven claim, rather than walking out of here thinking heās free to do as he pleases on his AMD CPU because itās ānot backdooredā and then end up rotting in a prison cell wondering day after day and night after night which aspect of his otherwise top-notch security got compromised. Priorities, my brother in Qubes, priorities priorities priorities.
Looks neat on the surface, but then I looked over their āWhat is Dasharo binary blob policy?ā on their FAQ and Iām not too impressed:
āIntegrate only the necessary amount of blobs required for proper platform operation and minimize the amount of blobs that are optional whenever possible by providing open equivalent implementations or removing them if there is no functional impact on the platform operation. Ultimately the blobs should be attested and properly documented. Dasharo Team is trying to achieve it by working on firmware SBOMs.ā
As you can see, it doesnāt mention the backdoor blobs specifically, nor whether they are part of the ārequired for proper platform operationā group or not. If I were a betting boy I would bet it is. What am I missing here?
Amen. More people need to know this.
Iām sorry but Iām gonna have to wait for some sort of community confirmation before I take this seriously. It cannot possibly be that simple. Where do I go to get these updaters? intel dot com slash backdoor slash updateā¦?
āCut the power lineā? What power lineā¦? And where do they sell pliers small enough to cut wires inside a CPU? I sure need me a pair of them
It is that simple. Ever get updates for the IME when running Intel? I have, many timesā¦ Just wait for that and do it then. but if you use āAutomatic Updatesā then you may never see it happen becausae you get the update from Microsoft that put in their own code for it and do the same thing essentially. Just like EFIā¦ Originally was good, then MicroSoft made it crap and full of holes. UEFI, the worst thing to exist. but thatās why I donāt use UEFI, and I remove it from the BIOS if I can. I dontā mean DISABLEā¦ I mean ERASE or REMOVE or REPLACE with open source non-UEFI but compatible processing of commands. Which is why I choose to OVERWRITE not just eradicate things.
Since sometimes functionality is required, you can get open source variants, and re-code them and add in and remove whatever you want to to make it more secure.
They also do that with IME. They have their own installer, have had since 2008 I think it was. So you can easily get and use that.
Use whatever you wantā¦ I can use a craft knife to do it. not that hard. Just find out the one that powers the IME and remove the Cap, done.
Iād like to point out that due to limited resource and architectural designing, Qubes OS relies on Xen and linux kernelās hardware compatibility. And Intel is more active than AMD in sending hardware compatibility patches to xen and kernel devel mailing lists. Thatās probably the answer to your original question: why does QubesOS support mostly intel computers.
Sounds like you have one of those motherboards supported by one of the open source BIOS listed earlier, because I canāt just inject random code into my motherboard and expect my system to boot.
I still find it hard to believe itās this easy. One would think IME checks its own updates for integrity before installing them. One would think Intel made the CPU unable to boot without IME (as alluded to in the Dasharo homepage I quoted earlier).
Can someone else please confirm @AWhiteās claims?
I donāt know much about RISC-V but from what I do know itās an open source platform, so I guess itās up to the individual manufacturers to get in bed with the feds or not.
I am following with great interest and trust the development of this project and I would like to know your opinion on the subject: Apple Silicon, through an Open Source operating system, could become a valid alternative for a privacy and security oriented system?
It would be fantastic if one day there was an ARM version of Qubes that can run on Apple Silicon.
Thanks for your welcome and authoritative opinions.
Apple hardware? For āprivacyā and āsecurityā?
Go back to your iPad. We do serious computing here.
ARM is spyware garbage, as is modern x86 and pretty much everything else made in the past 10-15 years. I recommend you look into RISC-V and OpenPower instead; thatās the closest we have to ācleanā hardware right now although both are still far from ideal.
The Triangulation malware was using a suspicious āhidden featureā
If we try to describe this feature and how the attackers took advantage of it, it all comes down to this: they are able to write data to a certain physical address while bypassing the hardware-based memory protection by writing the data, destination address, and data hash to unknown hardware registers of the chip unused by the firmware.
Our guess is that this unknown hardware feature was most likely intended to be used for debugging or testing purposes by Apple engineers or the factory, or that it was included by mistake. Because this feature is not used by the firmware, we have no idea how attackers would know how to use it.
" This puts them (Apple silicon) somewhere between x86 PCs and a libre-first system like the Talos II in terms of freedom to replace firmware and boot components; while a number of blobs are required in order to boot the system, none of those have the ability to take over the OS or compromise it post-boot (unlike, say, Intel ME and AMD PSP on recent systems, or the DMA-capable chips on the LPC bus running opaque blobs that exist on even [old ThinkPads](Technoethical X200 laptop | RYF))."
The Talos II mentioned in the quote is an openpower machine that is available (but not for a nice price):
A good working RiscV-implementation (above Raspberry Pi performance level, that is) is still not to be found. Besides ā¦ not everything is well made, just because it relies on open intellectual property. You could still built some bad design with it.
Concerning Apple ā¦ while they are more towards open boot with their Apple silicon machines for now (iPads or iPhones aside) they are as āopen doors and windowsā as x86 is, e.g.:
Donāt forget those ones either:
What about that nvme-controller? What about that NIC? What about that WIFI-card? (Atheros is considered āblob-freeā but that doesnāt mean itās free of proprietary firmware.) What about ā¦ younameit Etc.
If you have got ME disabled and a gpg signed boot environment like heads, you made a huge step forward in a certain area. But you are not safe in a broader sense. You just disabled one (rather hefty) security flaw and gained some control.
Again: it depends on whom you like to trust and whatās your concern. First and foremost itās as de-googled as it can get (like lineage mini). Second: it relies on a single app store (f-droid). It is heavily patched under the hood. It gets upstream security patches faster than anything else. The dev is well known and some of his code made it upstream. (Couldnāt be that bad.) The source is published.
But then ā¦ it relies on a certain hardware. Much more than lineage e.g.
So again, whom do you trust? (Me?) Maybe the attack surface for your individual needs and threat scenario is smaller on a Nokia C5 without cam and microphone (de-soldered) using a wired headset - disregarding any software aspects.
It all depends on how far you want to take it. You gain expenses and lose convenience the further you get to ātrue 100% privacy and securityā. The stuff Qubes recommends is among the best you can get when it comes to x86, but itās still x86, and unless youāre working with 10+ year old hardware, youāre going to have intentional backdoors.
I would recommend a Qubes certified system if you must have x86. In fact Iām in the market for one myself at the moment because I specifically need Qubes.
@OvalZero beat me to the Talos II but the Lichee Console 4A is a promising RISC-V laptop. They have other form factors too.
Iād still prefer a 4G router plugged into an old laptop. Graphene OS is nice but the hardware is still Google. You canāt de-google the hardware, only the software.
