Short list of laptops/desktops that work well with Qubes OS

I have the exact opposite opinion. The list is about computers that work well with Qubes OS and are in use by the community. That includes the certified and developer tested machines. I see no reason to separate them from the list. I also don’t think it looks better or more structured – quite the opposite actually it adds complexity and visual noise.

I also think this point was already discussed multiple times in the past and my impression was the consensus to include those machines in the list.

However, that is just my opinion and this is a community project.

I share your view, that it was the consensus, and that it is the right thing to do.

I never presume to speak for the Qubes team.

When I comment in the Forum or in the mailing lists I speak for myself.

A post was merged into an existing topic: TUXEDO Pulse 15 - Gen1

A post was split to a new topic: Unable to install

In light of QSB-081, should the inclusion criteria be expanded to require that the device’s CPU continues to receive microcode updates? Unfortunately, it looks like this would eliminate all but two of the recommended 4.1 models…

Related, more general discussion:


I understand the concerns about (the lack of) microcode updates, but have a few questions:

  • If we make the ability to receive microcode updates a requirement, why didn’t we make the ability to remove ME a requirement too? … funny enough that would leave us with exactly zero machines.

  • What about certified hardware?

At this point one pretty much has to choose:

  1. (minimized) ME and microcode updates

  2. no ME, no microcode updates

Maybe instead of a requirement, we can document the trade-offs and indicate in the table which category the machine belongs to?

1 Like

Because there is no evidence of active, widely available, serious exploits (at least without the AMT)? Because Intel supposedly only give the access to ME to NSA? (And if NSA is in your threat model, then you’ve got many more problems…)

I guess it should have a disclaimer, otherwise people might be deceived, thinking that it’s more secure than it actually is.

This might be an interesting read. Currently I don’t understand how to use a vulnerable machine, where any website could read all my passwords in RAM, including my HDD encryption password (if I understand the problem correctly). Never load any JavaScript?

Meanwhile, I guess more attention needs to go to this issue: Port Qubes to ppc64 [3 bitcoin bounty] · Issue #4318 · QubesOS/qubes-issues · GitHub.

Not an expert, but I may argue that probably yes.
Time to starting digging aroud SElinux in order to use it in HVM mode qubes (at least sys-net). Maybe grapheneos sys-net? Maybe i am digressing…

@fsflover it really doesn’t matter (to me) in the least that there is no published remote exploit for ME. When ME is present, there is an always on computer running proprietary code on my motherboard with full access to all hardware and completely transparent to any code running on the CPU.

QSB-081 starts: an adversary who controls a VM with an assigned PCI device can infer the memory content of other guests or Xen itself. So one would need to assign a PCI device to an HVM qube and then use it for web browsing to be vulnerable the way you indicated. If anything QSB-081 reinforces what should by now be a best practice among Qubes OS users due to the multitude of discovered and undiscovered side channel attacks on x86 CPU: when handling high value data, do so in an offline qube while all less trusted qubes are shutdown.

I fully agree with you that we desperately need a better computing platform for Qubes OS.

@qubicrm could you please explain why running an Android-based smartphone OS in sys-net would be an improvement? Or how SELinux would protect from QSB-081 or really any side-channel attack?


I don’t think you do understand the problem, although never loading
JavaScript is probably a Good Thing ™
The most recent QSB describes a situation where a compromised qube with
PCI may access data in RAM that pertains to Xen or some other qube. It
has nothing to do with websites leveraging JavaScript,( unless you
habitually browse from sys-net, which is probably a bad idea anyway).

Here is one way you could use a vulnerable machine to reduce the risk

  1. sys-usb:
    Only run when needed: shutdown when finished.
    Shutdown sensitive qubes before starting sys-usb.

  2. sys-net:
    Only run when needed: shutdown when finished.
    Shutdown/pause when performing sensitive operations in other qubes, as
    far as possible.
    Consider moving all possible activities away from sys-net ( date/time,
    updates, etc), and reduce profile as far as possible.

  3. General activities:
    Perform sensitive operations offline. (E.g use of GPG)
    Shutdown secure qubes when not in use.
    There are some activities which require sys-net to be active: e.g.
    email, ssh sessions. Restart sys-net before these activities to minimise
    the risk of leakage and compromise. Shutdown sys-net as soon as
    openssh protects private keys in RAM. Use split-ssh-agents.
    Use split-gpg.
    Encrypt data at rest.
    Use qubes-shutdown-idle (with short time out) to make sure that qubes
    close when not in active use.

Users may be doing some or all of this already.

I never presume to speak for the Qubes team.
When I comment in the Forum or in the mailing lists I speak for myself.

At this point, microcode update seems like a euphemism, the reality is that it is (critical) security updates.

I don’t think QSB-081 is the end of the world, but how unsafe can a CPU get before it’s a disservice to recommend it?

For the latest QSB, you are of course right. Are all other vulnerabilities were fully fixed for all Community-recommended laptops?

So, no usb mouse should be used. I guess we should use MacBooks, otherwise the touchpad may not be good enough for a daily driver…

We do not disagree here. I dream of a truly free machine, too. However, a machine that can be hacked by anyone vs a machine that can be hacked by NSA is not a hard choice I would say. Latest QSB can be somewhat mitigated as @unman explained, but what about earlier Intel vulnerabilities?

-1 Asus X540LA for Qubes4.0, everything works. Upgrading to 4.1 worked too. But only Max. 8GB RAM.
-2 NH5x_NH7xHP works with Qubes4.1, impossible to install 4.0 on it. And kernel-latest needed in Qubes4.1 on NH5x_NH7xHP

In in ideal world, I think we’d want to do that too, but as you point out, that would leave us with zero machines (if paired with this change), which would be impractical.

I’ve asked the devs about this.

Yes, it’s an unfortunate trade-off. This is also a painful situation, in general, for all of us who finally found compatible hardware and are now forced to either upgrade (with no guarantee that new hardware will be as compatible) or live with the new vulnerability.

That sounds reasonable. Since it’s the community-recommended hardware list, I suppose it’s up to the community to decide which way to go on this.

Indeed. And not just for Qubes OS! These hardware vulnerabilities affect everyone. It’s just that Qubes highlights them in ways that practically no other operating system or hardware vendor does. The world desperately needs more secure computing foundations.

Well, I’m not sure if I understand what you mean, but it’s not a euphemism, because we are literally talking about actual CPU microcode updates. In other words, it is a technical term being used accurately in a technical context.


@marmarek says, “Generally, having microcode updates for certified hardware makes sense. But I think in this specific case, it isn’t the end of the world just yet. And we need to change our approach to sys-net/sys-usb anyway (even if we have microcode updates).”

(Also tagging @Insurgo, since Marek said he and Thierry were recently discussing this.)


Will add my 2 cents here, while navigating through XSA/QSB is really not so easy for end users/anybody really, to have a clear view on status of things but added blind faith in protection without proper compartmentalization/prevention hygiene improvements that should be part of Qubes learning curve since meltdown/spectre of 2019 which literally tinted the sky to a constant ever reddish tone since then, which should influence since then Qubes learning curve to be conscious of what is in computer memory since then and proper compartmentalization/prevention opsec, which is what Qubes is all about.

Sorry in advance for the long post. Hope it will be useful…

On my end, I literally invested 8 hours (and counting…) re-digging into past vulnerabilities to confirm/infirm disclosed vulnerabilities and trying to go back to the source (Intel) to validate stated information, to realize that even Intel contradicts itself for Ivy bridge (common: Lenovo x230/t430/w530).

Again, if i’m saying wrong, please correct me (while I suggested to @marmarek to maybe have a specific section where that sort of thing can be discussed with more specifics), or even reply on the QSB which land in the forum? But that again might be a high source of spam, so i’m not sure how to correctly deal with this community problem/information sharing/fact/technical discussions without having the discussions at numerous places and then post here… This is really time consuming and not so productive.

So in the latest vulnerability disclosed (QSB-081-2022, XSA-404), in link with Ivy bridge, specifically:

  • SRBDS: Xen implements a workaround, disabling RDRAND and RDSEED CPU extensions. (so CPU based randomization is removed and not available from dom0).
  • TAA is non-applicable because TSX CPU extension doesn’t exist on Ivy.
  • MDS has microcode update and mitigation per MD_CLEAR reported status on Ivy.
  • Hyper-Threading deactivated to mitigate whole classes of shared core data exfiltration by qubes, implemented by default on Xen passed boot options.

So XSA-404 depends on the above to be successful. All of them? Partly? Which one for which part? What are the interactions needed between the above to launch successful attack?

People interested into digging into those status should get accustomed to digging into xl dmesg and reported dom0 cpuid information through cat /proc/cpuinfo to check exposed cpuflags and bugs sections, where again, the latter might be misleading to the user and also needs deeper validation and cross-fact-checking, since the kernel reports its status based on different facts, some of which are false positives as well. So i’m opening the can of worms here, also hoping for collaboration following what will be picked in this opened can and which worms will be looked at.

cat /proc/cpuinfo | grep flags

flags: fpu de tsc msr pae mce cx8 apic sep mca cmov pat clflush acpi mmx fxsr sse sse2 ss ht syscall nx rdtscp lm constant_tsc rep_good nopl nonstop_tsc cpuid tsc_known_freq pni pclmulqdq monitor est ssse3 cx16 sse4_1 sse4_2 popcnt aes xsave avx f16c hypervisor lahf_lm cpuid_fault ssbd ibrs ibpb stibp fsgsbase erms xsaveopt md_clear

cat /proc/cpuinfo | grep bugs

bugs: cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs itlb_multihit

xl dmesg| grep MD_CLEAR


So in the current XSA-404 vuln, which is linked to past SRBDS, TAA and MDS vulnerabilities requiring microcode updates, it seems that for Ivy bridge, the sky is not totally in fire for the moment. Newer CPU architectures expose new CPU extensions which in turn were vulnerable and needed microcode patching.

But outside of part vulnerabilities not affecting Ivy (RDSEED and RDRAND extensions disabled by Xen (SRBDS) and not exposed above in cpuinfo output, TAA depending on TSX (not available on Ivy, not exposed in cpuinf above) and MDS having microcode update to issue MD_CLEAR, exposed in xl dmesg above) some concerns are still present:

  • DRPW vuln, specific for XSA-404 is still a thing for PCI passthrough enabled qubes (sys-net and sys-usb) depends on present hardware and connected PCI devices design faults, which I cannot still today confirm/infirm, not knowing how to. Is Atheros AR5BHB116 wifi card vulnerable? Is the sys-usb at risk? I did not find relative information.
  • Other MDS vulns were disclosed (SBDS, SBDR) which MD_CLEAR might/might not be enough to mitigate, depending on corrections of microcode updates in 2019 and other CPU extensions involvement to have successful attacks. I did not find relative information.

The quick conclusion here is that today, the most severe impacts of XSA-404 does not seem to apply for Ivy bridge based platforms. An end-user would still be on the safest side lowering trust into sys-usb and sys-net a little, as stated by @unman in his post in this thread here

As to the wider debate: yes, we need more open hardware, but doing that on Intel/AMD is not easy/impossible. Not going to jump into the newer Intel/AMD platforms’ ME/PSP AGESA/FSP, MRC init, EC controller and HDD/SSD firmware blobs issues we still have here on all available hardware, more recent the worst, but we are in a really weird place when it comes to doing/choosing hardware/architecture because of false choices/bad assumptions on hardware openness, platform components openness, their firmware openness…

Other architectures, more open in theory but not necessarily in practice are neither Xen supported, nor have enough processing power or not enough RAM, where most of them also come with their PSP/ME and/or AGESA/FSP and/or MRC equivalents… Coreboot and openness/user control are not equivalents terms and this is also another messy subject which should be debated in another thread or even upstream! Coreboot developers, why not pickup this abandoned merge request to finally document coreboot platforms blobs requirements for easier understanding?

To have choices, those need to be created first, then supported, then have Qubes deployed on them by OEM (Qubes Certification).

How do we resolve those complex chicken-egg problems? I’m not quite sure, but by providing possibilities and trying to be the clearest possible on what are the limitations/features of each platform and… delegate that choice to end users to do proper choices, but all of this is complex and hard to wrap in entirety even for knowledgeable people. The ideal here would be the whole community standing up and say: Take my money and create this Power based laptop, have enough money to have coreboot support on it, thorough testing, have Xen support then Qubes support without that work taking 10 years before arriving to end-users. But the thing here is that end users wants it now, and want to buy as cheap as if they were buying laptops at Walmart. All of those are simply impossible to achieve without a much deeper collaboration, so I state again: I do not know how to accomplish this incredible mandate, and just maintaining Heads for existing platforms, already supported by coreboot, is a tremendous task on itself. And then juggling with internal Qubes chances, bugs etc to deliver something that is ready to use without sacrificing security for convenience is another really interesting challenge. My line here would be: if there is a platform that is freedom-respective, open and supported by Xen today, already ported to coreboot and ready to integrate under Heads, please PM me and I will be more then happy to have that certified and merge efforts in some kind of healthy partnership to not have to do all the other work and maintain it all on my own :slight_smile:

In the case of Power, there is no concept of microcode updates. So for the disaster that happened in Spectre/Meltdown, IBM released a Power9 v2 CPU, needing customers to replace their socketed CPUs to mitigate the issue, while introducing Ultravisor at the same time. Xen port is ongoing, but inflation is a real problem for quick advancement. Then Qubes will need to be packaged on it. The good news there is that there is already owners of the Talos II boards, so the coreboot port, with TPM support, will not be hard to test for current owners. Same for Qubes ALPHA iso images, when we are there. But in the context of creating a new platform, coreboot port, qubes port etc… Users wanting this will need to show up and give an hand if not a bunch of money so we can get there. The whole concept of having a ready to buy product won’t happen unless a millionaire (billionaire?) jumps in the mission. Maybe this message will make its way… Otherwise grant application and its associated work goes slow. Community small donations are welcome, but are not enough. This would need a massive joint work between IBV/OEM/coreboot devels/Xen devels/Qubes devel to come to end users in less then 2 years from now.

Long story short, as of today, current best coreboot native init platform and user owneable, without FSP ME, that is those old 2012-2013 manufactured Ivy bridges are not yet exposing microcode-only fixable vulnerabilities. In the current XSA-404 case, the missing information is to know if WIFI mini-pcie card is containing a design flaw which would have the device deal incorrectly with writes of incorrect sizes, combined with user carelessness happening in those service qubes, more specifically sys-net as adressed above. Why on earth would you do anything under sys-net, other then having that qube physically/wirelessly connect to networks with NetworkManager GUI, have NTP for dom0 to fix RTC clock, set firewall ingress settings and make routing of packets available for other internet needing qubes, again?

But yes, the sky is uncertain to say the least. Will a day come with a vuln that requires a microcode update without mitigation? The answer is without a doubt: mostly probably, yes. Meanwhile, if you want to see how much the sky is really in fire, follow the rabbit here: Low Level PC/Server Attack & Defense Timeline — By @XenoKovah of @DarkMentorLLC

Meanwhile, and I keep saying those things to customers; proper hygiene without implying irrational faith in protection offered is kinda of the only way forward… We are dealing with blackboxes on each level on newer architectures, and this is a blind faith trust model. But having sys-net/sys-usb as disposable service qubes, not having sys-usb started on boot if device is to be left unattended, not having sys-net automatically connect to network on boot are all threat model relative questions and possible mitigations. But again, if convenience wins over security for you, those choices are still choices which should be calculated in risk mitigation and risk exposure tolerance.

That is all I can say today, folks.

Feel free to move this post where it should belong and link to it from here if that is done.


I am not a programmer, so take my comments with a grain o salt. That said, it seems to me that android is now much better than linux regarding security . It also seems to me that the better security comes from the applications of several mechanisms, including severe containment of what running process can (or not) do. Can selinux make a system immune to a kernel exploit? Are there demonstration of this? Sincerely i am not sure.
I think android comes in second to qubes regarding security and freedom. So if wr could port some well done things to a Appvm, it would be great.
probably i do not know enought, but would like to learn from the comments i read.

Qubes OS relies on a totally different approach to security: security through compartmentalization. One could probably even say that security of underlying VMs is not (directly) a problem of Qubes. Of course, you might gain some security by using a secure OS in a qube, but it’s a much weaker protection (with many more regular exploits) than the hardware virtualization. More discussion: WTF?! Passwordless Root Access in VMs?


Yes. i am aware. But i am inclined to think all this assumes a solid hardware. If xen runs on top of a rooten architecture. (It would be good if qubes could run on ARM.).
If we accept these reasoning, could it be helpful to raise the bar inside each VM.
Whonix is going in that direction, it seems, with appArmor, kernel hardening, strong user separation. Some of these are certainly usefull even in qubes (or some use cases under qubes)

There are no vulnerabilities that can only be used by certain people. You know that.

I am not saying it’s a good thing to not have these microcode updates, although some people in some circumstances decide that they don’t want them. There is also the issue of these updates themselves being closed source and not available for audit.

It’s imperfect choices all around. Coming back to @adw’s question: if we make microcode updates a requirement we end up with a list that has only the ThinkPad P51 and the Purism Librem 14 on it. Once we start making requirements in that direction, we should also require at least a minimized ME. That would result in the Purism Librem 14 being the ONLY computer currently than can be recommended.

I am sure you would like that, but I am not sure this would be a good thing for the project.