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
(XEN) Hardware features: IBPB IBRS STIBP SSBD L1D_FLUSH MD_CLEAR
(XEN) Support for HVM VMs: MSR_SPEC_CTRL RSB EAGER_FPU MD_CLEAR
(XEN) Support for PV VMs: MSR_SPEC_CTRL EAGER_FPU 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 
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.