I covered things back in 2022 https://forum.qubes-os.org/t/short-list-of-laptops-desktops-that-work-well-with-qubes-os/5197/245

Thing is situation is different now since new research confirms that if things are aligned differently, previous speculation mitigation can be bypassed altogether.

Best I could do now is cross-link things

• https://forum.qubes-os.org/t/short-list-of-laptops-desktops-that-work-well-with-qubes-os/5197/326
• https://forum.qubes-os.org/t/qsb-107-multiple-cpu-branch-prediction-vulnerabilities/33925/2

Hopefully, this issue will get enough attention so that we, as an ecosystem, document this properly.

@tlaurion Should all vulnerable platforms be moved to LIKELY_UNSAFE category? The label perhaps should also appear in the rom name? So, in case of folks building the HEADS themselves or downloading the rom they are at least triggered to ask or search info in the docs? As the experience shows, very few indeed study the docs in detail…
In general, it is quite sad that we all are forced to accept the more blobs and „buy recent hardware“ policy from big techs. But perhaps this is inevitable reality.

Can you qualify what you mean by "forever"?

Is there reason to believe future software mitigations are impossible?

I understand currently only CPU microcode updates remediate the vulnerability and all EOL CPUs aren't getting microcode updates.

I searched far and wide for any indications of software mitigations being off the table, but didn't find anything. Am I missing something? Are software mitigations CPU independent? If they are CPU dependent like microcode updates, then I can see a world where only >8th Gen CPUs get software mitigation solutions and can understand the pessimism. Some insight is appreciate on this.

From the Researchers' blog post:
https://comsec.ethz.ch/research/microarch/branch-privilege-injection/

We have also evaluated several potential alternative mitigation strategies in software with overheads between 1.6% (Coffee Lake Refresh) and 8.3% (Rocket lake). Please refer to our paper for more details.

I've gotten the sense that a large part of the QubesOS/Heads community has given up on old hardware. Am I crazy to think it's too early to call it so decisively?

@thickfont Perhaps it is not that bad as it looks…and you indeed may be correct. I think now there is no PoC on Qubes OS. Did you read the paper in more detail? I just did. They used KVM and run everything on host system kernel in hypervisor attack. So the situation in Qubes is different as from the Marek answer in matrix forum in Qubes channel „ dom0 is privileged VM.“ So perhaps, disclaimer i am not an expert in the field…it is still okay to use older hardware. In the paper, also a software mitigation was described: retpoline it was not helpfull against all types of attacks. But all the things should be proved, until then then we need to assume the worse….

Edit: we perhaps just need to test the vulns first on our hardware with ubuntu installed.
@tlaurion did you have a chance to test your x230? I will try to test my t430.

Updated threat modeling page to point to relevant Intel pages at linuxboot/heads-wiki@68301d7

Still unsure on #1976 (renaming boards to LIKELY_INSECURE is way too long board names, to be honest Threat model page should be enough with warning in boards configs affected?)

Updated threat modeling page to point to relevant Intel pages at linuxboot/heads-wiki@68301d7

Still unsure on #1976 (renaming boards to LIKELY_INSECURE is way too long board names, to be honest Threat model page should be enough with warning in boards configs affected?)

I reverted radical changes (board rename) under #1976 : for now, vulnerable boards have big fat warning added under board configs.

@JonathonHall-Purism @marmarek further advice?

@thickfont Perhaps it is not that bad as it looks…and you indeed may be correct. I think now there is no PoC on Qubes OS. Did you read the paper in more detail? I just did. They used KVM and run everything on host system kernel in hypervisor attack. So the situation in Qubes is different as from the Marek answer in matrix forum in Qubes channel „ dom0 is privileged VM.“ So perhaps, disclaimer i am not an expert in the field…it is still okay to use older hardware. In the paper, also a software mitigation was described: retpoline it was not helpfull against all types of attacks. But all the things should be proved, until then then we need to assume the worse….

qubes-public matrix discussion input by @marmarek

I am reaching you regarding the QSB-107. I read the QSB-107, the paper from ETH (https://comsec.ethz.ch/wp-content/files/bprc_sec25.pdf) and looked at their github repo. The guest to supervisor attack was done on KVM. Does the concept work on qubes/xen? Did somebody really check the PoC? To enable the PoC an update of the GRUB config is nessesary ´´´update the GRUB_CMDLINE_LINUX_DEFAULT by adding "nosmap nosmep clearcpuid=295,308 mitigations=off"´´´. I believe that must be done from dom0 first correct? Since, I lack the expertise the confirmation of the attack working on xen, taking in considiration the severity of the impact, could really help numbers of community members still using older hardware.
their PoC would require very substantial changes to work on Xen, as it currently a) uses KVM API for creating a VM for test, and b) assumes you run it on the host system (the kernel which hosts hypervisor), while in Xen, you don't have that possibility at all - dom0 is just another VM (privileged one, but still a VM)

On which I have not much to add.

Edit: we perhaps just need to test the vulns first on our hardware with ubuntu installed. @tlaurion did you have a chance to test your x230? I will try to test my t430. @thickfont can you check t480s? I now do not have any spare ssd to install ubuntu on my t480. Not sure wether live ubuntu will work…

My practical, QA perspective answer:

• We could test, yes. But my take is that qsb-107 makes me personally not want to recommend the x230 for qubesos users looking for a plug-and-pray experience anymore (where users are expected to run tor browser in a dvm alongside their vault's keepassxc open database and their LUKS container opened, decrypted... With untrusted qubes running overnight that could potentially exfiltrate data at around 5.6kib/s for available, yet not reproduced on Ivy bridge, rate. I know its "use it at your own risk" in the open source world, but having sold hardware, having done paid support for QubesOS users.... We have to be honest here. Most want/act a plug and pray experience. Ivy bridge x230: 3rd gen Intel CPU) up to 8th gen intel CPU will not receive any microcode updates anymore (gen 8th last microcode update to be received forever was 31 december 2024: this is t480 btw), so No I do not feel comfortable recommending those machines for a plug-and-pray experience (hear me out:I am always against plug-and-pray experience, contributed to a lot to opsec articles in the past having been written, but people don't read. One such good article is https://www.anarsec.guide/posts/qubes/

I am not anymore comfortable recommending hardware that is not tested anymore in any serious article (x230).
I was felling uneasy at https://forum.qubes-os.org/t/short-list-of-laptops-desktops-that-work-well-with-qubes-os/5197/245, now i'm not comfortable. Will retpoline realignment fix the day? Maybe.

But yet again, hear me out.

• using x230 for whistleblowering, to boot Tails on a single purpose workflow, where no states are to be kept on the machine: yes. Still yes. Lesser blobs level, people using Tails typically more conscious of states, or scared of them; they do not wish a plug-and-pray and will use the bare minimal needed in their work session and poweroff when they are done. They will follow good opsec like https://www.anarsec.guide/posts/tails/
• using x230 for qubes workflow: means a lot of states to be protected. People using Heads (other side of tails) is typically to safeguard their qubesos workflows. So here again, if goal is to leave laptop powered on for days with unsafe workflows in parallel of doing private computing: this is not recommendable anymore.

My theoritical background based answer:
The problem here @notgivenby with retpoline is that at the time it was introduced, there was traction for vulnerable systems that would/could not receive microcode updates already. Embargoed work happened under linux kernel in December 1997 up to public vuln disclosure in Jan 2018 for Spectre/Meltdown. To be noted that Spectre V2 was never fully patched by microcode updates for Ivy bridge and Ivy bridge was vastly used back in that time: those speculative vulnerabilities being a first in computing history with such massive impact and creating such havoc. That was 2018, retpoline since then went dynamic if no microcode available, and all was somewhat still ok with conditions to trigger other important vulns not all being theoretically met to recommend Ivy bridge to be retired; but this is somewhat different now. We are now in 2025: retpoline is used only for now really old hardware; there is recommendation to recompile with reallignment; the rest of the world moved away of older hardware not receiving microcode updates; the world took for granted that even hardware becomes obsolete and some processor designers took some shortcuts while others didn't, AMD was supposed to supersede Intel in sell numbers because of this Spectre but none of this really happened. Microcode updates became more important; AMD still is slow releasing mirccrode updates (read QubesOS ocs on that) and Intel is still the recommended CPU maker for compartmentalization; others still not supproted by QubesOS, some not yet supported by Xen.... Power 10 architecture contains blobs, Risc-V still not fast enough and not completely open docs/IPs, ARM IP became a little more interesting somewhat, but still no QubesOS...

TLDR: since 2018: the world accepted that CPU have programmed obsolescence as well as for their phone, cars, and anything having electonics, software and firmware (blobs), even more importantly for confidential workflows; microcode updates are offered for a platform around 6 years after manufacturing date and this is the world we live in now.

Sorry for the long post.