Thank you for the reply @unman , but the link you sent says it is also compatible with Librem 14. So what is the difference? Is it possible to say that Librem 15 or Nitropad is “safer” to use with Qubes?
If Purism can effectively disabled Intel ME and their deactivation procedure is trustworthy, does it even make sense to use older CPUs (approx 30% performance increase of 3rd gen i7 vs 10th gen i7 + lighter laptop, faster ssd, more ram, etc.)
Sorry for the possibly stupid questions but this matter is still not clear to me, I would like to buy a Qubes compatible laptop and I am deciding between a Librem 14 and a Nitropad T430. The requirement is deactivated (trustworthy) Intel ME, coreboot/heads. Then if both devices are identical the preference is which is lighter (frequent travel) and has faster RAM and SSD and more RAM.
Another difference is of course price. A Librem will cost you anything in between $1,570 (8GB and 250GB SSD – useless for Qubes OS) and $3,366 if you want more 64GB RAM, 2TB SSD and actual heads/anti-interdiction services.
To make a fair comparison let’s configure 16GB RAM, 1TB SATA SSD, heads/Librem Key without anti-interdiction … Purism = $2046.00 / NitroPad = 1,314 € (~ $1,500). If you build that “NitroPad” yourself you can have the same machine for < $1,000 with even better specs incl. full HD screen (I have done it, building a second one in the next days). You could probably do the the exact NitroPad spec for < $700.
Those price differences might not be a big deal to you, but there are plenty of folks for whom that is the difference between possible and impossible. Finally, I can’t speak to how well Purism laptops are supported, but the T430 is pure pleasure. Everything is supported and works (makes sense since the tech is 10+ years old).
A Librem will cost you anything in between $1,570 (8GB and 250GB SSD – useless for Qubes OS)
Could you please explain why 250GB SSD is useles for Qubes? I noticed that you can configure Nitropad X230 with 480GB SSD.
Keep in mind that while older notebooks like T460/X230 etc can properly disable ME and have coreboot support, they are no longer supported with microcode updates. With all the CPU sidechannel vulnerabilities these days, that may be a risk in your threat model.
I found this statement on this forum. Is this a relevant threat for Nitropads? If so, what measures are taken to mitigate the risk?
What about similar risks from outdated and potentially vulnerable firmware of other components and drivers on older notebooks like Nitropads?
If I put all the information together, is it right that there are no disadvantages in terms of security when using a Librem as a basis for Qubes OS (preinstalled) except the following?
not certified by Qubes team
lack of clarity about how Intel ME is disabled
Could you please tell me if Intel ME is disabled or neutralized on Nitropads as I could not find this detail in the available information?
I would like to add that Purism finalizes assembly, quality control tests, and delivers hardware from USA based on their information. How do you rate this?
In addition to what others have mentioned (e.g., cost), there is simply the practical matter of support for end users. As Unman mentioned, me_cleaner only supports up to Kaby Lake processors, probably because well supported - community driven solutions lag profit based businesses (e.g., Purism, System76) due to funding/resources. You can see this with related solutions, as well, such as CoreBoot. So, if you want access to a stable ME solution with good support, and an affordable price, “older” technologies are a good option.
You can’t reduce IME, but you can disable it with the HAP bit, which seems to be confirmed working up to and including 11th gen intel.
Most people don’t buy CPUs with the vPro features, and without vPro IEM doesn’t include AMT. As fare as I know, all RCE exploits against IME have been in the AMT extension. If you have a CPU without ATM, I don’t think you need to reduce IEM, but I could be wrong on this.
This thread has a lot of info from the work dt-zero has done after corna stopped working on the project, but I also think real life work has forced dt-zero to stop working on the project.
That’s really great information. Intel’s vPRO/AMT is always worth considering when selecting and configuring a device. The HAP bit mod is a new one on me, so thanks.
I could have been more artful in my response to the OP who seemed to be asking the question: “Why not the latest and greatest CPU for a Qubes OS platform?”
A more refined response, on my part, would have been to say that one needs to consider personal interests/requirements as well as the total cost of ownership (TCO) both in terms of money and one’s personal time.
If you’re an organization or individual with deeps pockets, or if having the latest and greatest is your thing, then there’s absolutely nothing wrong with running with a Purism device with a Comet Lake cpu. The Qubes Hardware Compatibility list has listed some great options.
If you’re someone who has the technical savy or “spirit of adventure,” then the The Qubes Hardware Compatibility list documents the hard work of those who have contributed their experience with a multitude of platforms, and that should prove useful.
If you’re an individual or ogranization looking for a Qubes OS device option with the lowest TOC (Money & Time), then the Community Recommended Hardware List provides some well thought out options. I’m personally in this camp, and am planning to pick up a t430 with an i5-3320m and 8 GB of RAM in the next few months. The prices are dropping (currently under $100) on the online auction sites, and availability of replacement/upgrade parts is far superior to the Sony Vaio’s I’ve been using and abusing for years.
IMHO, there really isn’t a “right” answer regarding the best choice in CPUs or devices for Qubes OS. Rather, a choice of options one of which will likely best suit your own use case. Picking up a t430 (i5-3320m) provides a very cost effective solution with a great level of compatibilty and community support. Moreover, you can upgrade at your leisure (e.g., 4 physical cores via a i7-3840QM) and others have made a shopping list for your convenience.
You can’t clean IME anymore, so it’s true that me_cleaner doesn’t work.
One of the options me_cleaner has, is to soft disable IME using the HAP or AltMeDisable bit depending on the version of IME, this method still works if you do it manually. The theoretical problem with this approach is that there is no way to know if IME is running, it could be running and just telling the system it’s not.
Cleaning IME is probably the more secure option if you look at it in a vacuum because it removes the code from the ROM, even if IME is running there is no code for it to execute.
But given up microcode updates and secure boot is not a small price to pay for getting the option to remove the code from the ROM. It’s not something for nothing, and if you gain or lose security depends heavily on your personal threat model.
I have not been able to find any evidence of vulnerabilities as threatening as Intel ME for Qubes certified laptops (Insurgo X230 and Nitropads X230 and T430) regarding CPU microcodes or other firmware for mainboard, network card and hard disks (latter probably less relevant) because of missing updates. Does anyone else has information on this?
The best video I’ve seen on the matter of the ME was an interview by Bryan Lunduke that included Jeremy Soller of System 76. The video has since been pulled, but I do remember Jeremy saying that with the best “counter measures” there’s still a split second handshake with ME at bootup. I don’t recall them elaborating on what the handshake or modifications mean in terms of vulnerabilities. However, Jeremy seemed well informed and might be a good source of information.
You are mixing the features of Intel management Engine and Intel Active Management Technology, only the vPro line of CPUs have the AMT functions. IME can’t be disabled, but you can disable AMT in the bios.
You can compile Coreboot with the log enabled, it allows CB to write some KBytes of the firmware boot log to the firmware rom, once the system is booted you can extract the log with the flashrom util. I don’t think CB knows more than IME is telling it, a paranoid person probably wouldn’t believe that IME is telling the truth.
For the X230 and T430, it’s probably better to just remove IME, considering they are both vPro. The CPU and laptop is discontinued, you don’t get any microcode or firmware updates, but it does mean you can’t use anti evil maid.
I’m not sure if you were replying to my post, as I don’t think I was disagreeing with you. I was simply noting a resource, who is active on social media, with a strong understanding of how to slim down the Intel Management Engine.
System 76 (Jeremy Soller) uses processors that are not VPro “ellibible”, so as far as I know, AMT functions are not available. However the chip set on the motherboards most likely have the Management Engine, thus why they slim the Management Engine down.
The “handshake” Jeremy Soller mentions likely involves the Management Engines involvement in the initialization process at a point prior to which the “slimming down” takes place (see stage 4 vs stage 5).
Of course, Jeremy Soller was referring to newer proccessors & chip sets, and the technologies (harware & firmware) on which AMT and the Management Engine (arguably an element of AMT) have evolved over the past decade or so.
I think the definition on wikipedia is in the ballpark, but not completely accurate. AMT is a set of functions that can be enabled by configuring specific vPro technologies (key being cpu, chipset & wired & wireless lan adapters), not just the cpu. Initially, it was just the lan adapter.
@unman I take the responsibility to correct the facts based on the work that happened from Heads (Trammel actually discovered that getting rid of some ME regions was not causing laptop shutdown 30 minutes later) and then me_cleaner picked up the work, and then Positive technologies advanced knowledge and HAP bit, which was then iteratively added under me_cleaner, until me_cleaner got unmaintained.
The short version of this is that ME <10 can be deactivated + neutered (meaning that all modules outside of ROMP and BUP) can be removed. (where ME <6 could be completely removed but out of interest to Qubes OS: the x200 being a platform example).
That includes xx20 (Sandy bridge) which can be neutered to only have BUP (minimal requirement to BringUP the platform) and xx30 (Ivy bridge) which added ROMP as a requirement and cannot be removed. The best link to understand what happens when neutering is from me_cleaner doc here for those platforms: How does it work? · corna/me_cleaner Wiki · GitHub
Me > 11 adds Kernel and modules to non-removable modules. The correct term here is then deactivated (HAP bit) + minimized (not neutered anymore). The best documentation to understand what changed under ME > 11 signature scheme is again from me_cleaner documentation, this time under this link: How does it work? · corna/me_cleaner Wiki · GitHub
So newer platforms including ME (now named Converged Security Management Engine (CSME)) can still deactivate ME (with HAP bit) where minimizing is now limited since Intel adapted their signature scheme to encompass modules that now cannot be removed.
The goal is not to feed FUD, but be conscious of what is there, updated in firmware updates, new CPU extensions being present in newer processors, microcode updates presence or not. I replied under Short list of laptops/desktops that work well with Qubes OS - #245 by Insurgo as well to debrief on XSA-404 affecting Qubes and covered under QSB-081-2022. Those are complicated matters, once again…
