Looking at the certified hardware list, there are three laptops based on ancient hardware that no longer receive microcode updates or firmware updates nor do they support modern security features like Intel TXT or Intel Bootguard. Additionally, the Starlabs Starbook also does not support Intel Bootguard.
I believe this is puts users at a disadvantage for users as they may believe that they are secure just because they are using Qubes OS but the reality is that they have not considered the security of their hardware. There have been numerous discussions about secure hardware on this forum before, delving into much more detail than I currently am because this is not the main topic of my post.
I am not sure of the security state of the Nitro PC or the Dasharo FidelisGuard Z690. The NovaCustom NV41 is on the right track, with there being plans to implement Intel Bootguard in their next firmware update. Here is a good discussion to read more about it. I hope this thread does not turn into another Intel ME argument as this has already been discussed to death.
This leads me to my next point. The certified hardware list should add something to their criteria. I propose mandating that the hardware that is being tested reaches a minimum of level 3 on the HSI specification. This is what NovaCustom is aiming for with their NV41 laptop. The command fwupdmgr security (to test the HSI level) does not work on Qubes however, but can be tested on a live Linux OS for example.
There could be different threat models, for example, the hardware could be protected from the physical access and the goal is to protect it from the remote compromise e.g. in case of the compromise of the vendor Intel Boot Guard keys and LVFS access the attacker can send you malicious firmware update.
In my view one of the pillars for security of Qubes OS is to provide an abstraction layer of (most) hardware, so that it is not directly accessible for software.
Hence I think
as long as your system hasn’t been corrupted in a persistent way before Qubes installation
you trust in Xen as hypervisor
and have a similar threat model to what @apparatus mentioned
, there are many good reasons to install it on uncertified hardware (even beyond security).
I think if an attacker is investing a huge amount of resources into personally targeting you with a malicious firmware update, they would have no problem trying to physically access your laptop.
Basic protection but any failure would lead to a critical security impact.
This security level corresponds to the most basic of security protections considered essential by security professionals. Any failures at this level would have critical security impact and could likely be used to compromise the system firmware without physical access.
Either way, if one’s threat model would be protecting against remote compromise, they would still need at least HSI:1, which the older laptops certified by Qubes OS do not provide. You can see the tests that are required for HSI:1 in the HSI specification link I listed earlier. I think it is safe to assume ancient CPUs that have not received microcode updates in almost a decade are lacking protection against a ton of CVEs which may include vulnerabilities that can lead to remote compromise.
Although it is true that Qubes does this through requiring features such as VT-x, VT-d, and SLAT, these do not protect against malicious firmware being flashed onto your laptop without your knowledge. You would need Intel BootGuard to prevent your laptop from running this malicious firmware and establishing a good root-of-trust.
Again, these do not protect have anything to do with protecting against the firmware of your device. You need a good security base for the hardware in order to make sure you are safe when using Qubes. A good security base for hardware would mean the CPUs are recieving microcode updates, firmware on internal components of your device is being updated, Intel BootGuard is set up properly and many other things listed in the HSI specification.
I don’t know what you mean. This is not about uncertified hardware.
They have ME removed, and the firmware replaced with Coreboot which does receive updates. You can check with lscpu which vulnerabilities affect the cpu, and what mitigation is being used.
The X220/30 and T420/30 are the oldest laptops recommended, and they are still safe to use.
I’m not so sure, CPU microcodes are different from the system firmware. If there is a CPU vulnerability that is not patched, it will never be patched as only intel should have the knowledge/skills/documentation to do so.
I do not think anyone is arguing that these CPUs have recieved microcode updates and are fully up-to-date regarding CVEs. The only assumption I made was regarding that the unpatched CVEs would lead to remote compromise as I do not have any information regarding this.
I do not see how this is relevant to CPU microcode. Additionally, if one’s threat model is a backdoor in the Intel ME, then by all means, use a laptop that does not include it. That is not the point of my forum post though.
Bold statement to make. Even if none of the currently discovered CVEs that the CPU is vulnerable to lead to remote compromise, you cannot argue that running a CPU with unpatched CVEs (that will never be patched) is safe.
I highly doubt that the portion of Qubes OS users that need to realistically protect against hardware backdoors in their threat model make up a majority of the Qubes user base. Those people have very specific needs and already know what they have to do to achieve their goals.
It makes the most sense that someone just starting out with Qubes OS, probably with an average threat model, would consider reading the Certified Hardware list to find a laptop that “just works”. So it would be in their best interest that Qubes certifies laptops with good hardware security so that with any purchase they make, they are already reasonably protected on the hardware front.
As part of my suggestion in the initial post, I suggested that certified laptops reach HSI level 3 (HSI level 2 would be reasonable as well imo) although HSI level 4 exists. This is because the only requirement for reaching HSI level 4 is having encrypted memory which is too extreme for average users. Similar to the folks with hardware backdoors in their threat model, someone who has a motivated attacker that is trying to gain physical access as their threat model, would know that they need encrypted memory on their devices and how to get it.
The entire point of my proposal is for average users, who know nothing about hardware security and are looking for a Qubes laptop, to have reasonable protection from the get-go. I believe the current Certified Hardware list does not achieve this.
It could be a widespread attack, not only a targeted one.
And not in every case gaining the physical access to the machine is easier than getting the vendor keys and access. Especially if the attacker is a state that can easily get the keys from the vendor.
It’s not enough to protect the user from the attacker with physical access by having only Intel Boot Guard, sure you’ll prevent the attacker from flashing malicious firmware, but attacker can just place the malicious binaries in your efi/boot partition.
This can be protected by TrenchBoot, but it’s not released yet.
So is the only hardware that should be certified right now is the one that has unfused Intel Boot Guard so user can use their own key and use Heads?
Everything doesn’t need to be fixed with microcode, both the kernel and hypervisor can provide mitigation.
This is my x230, it’s running SMT enabled which isn’t recommended because it removes mitigation for mds and mmio, but that is true for even modern CPUs.
Vulnerability Gather data sampling: Not affected
Vulnerability Itlb multihit: KVM: Mitigation: VMX unsupported
Vulnerability L1tf: Mitigation; PTE Inversion
Vulnerability Mds: Mitigation; Clear CPU buffers; SMT Host state unknown
Vulnerability Meltdown: Unknown (XEN PV detected, hypervisor mitigation required)
Vulnerability Mmio stale data: Unknown: No mitigations
Vulnerability Reg file data sampling: Not affected
Vulnerability Retbleed: Not affected
Vulnerability Spec rstack overflow: Not affected
Vulnerability Spec store bypass: Mitigation; Speculative Store Bypass disabled via prctl
Vulnerability Spectre v1: Mitigation; usercopy/swapgs barriers and __user pointer sanitization
Vulnerability Spectre v2: Mitigation; Retpolines; IBPB conditional; IBRS_FW; STIBP conditional; RSB filling; PBRSB-eIBRS Not affected; BHI Retpoline
Vulnerability Srbds: Not affected
Vulnerability Tsx async abort: Not affected
That is true and again, if that is realistically within your threat model, then act accordingly. That is not the point of my suggestion though, please refer to the last two paragraphs of my previous post.
Of course, I just only mentioned Intel BootGuard only for simplicity’s sake. Other factors are important if your threat model involves attackers trying to get physical access. DRAM memory encryprion, DMA protection, pre-boot DMA protection, firmware rollback protection, AEM and others.
I didn’t say that. The majority of users do not have state actors as their threat model and would not require unfused Intel BootGuard. Again, referring to my previous post, my suggestions are for providing reasonable security for the majority of users with an average threat model. There is a discussion about flaws with Heads here.
I don’t think Heads is the way to go. When Qubes supports Secure Boot and TrenchBoot supports UEFI and upstreams it to Qubes. Combining this with hardware that implements HSI:2 or above, that would be the ideal setup for average users imo.
The only issue with Heads is that attacker with physical access can flash the malicious firmware without Intel Boot Guard. That’s why I mentioned unfused Intel Boot Guard, with it user can enroll their own key and sign the Heads firmware with it so attacker won’t be able to flash malicious firmware.
Ah I see. I am not deeply familiar with the issues around Heads because I do not plan on using it. NovaCustom laptops are currently unfused and the fusing process for Intel BootGuard will be optional with the next firmware update. They also support Heads firmware.