-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.
2 Likes
@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.)
4 Likes
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.
10 Likes
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?
2 Likes
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.
3 Likes
This.
2 Likes
Alright, in short:
-
sys-net’s only job is to interface with the networking hardware and provide that connection to other qubes; even if you’d use Android, the part of it that would do the sys-net job would be the Linux part. So all the stuff that makes Android would simply be unused, eating up disk space and increasing the attack surface. Not much sense it that.
-
SELinux deals with protecting the Linux kernel. Side channel attacks do not need to exploit the Linux kernel to work. Not much sense in that, IN THIS CONTEXT either.
I don’t want to discourage anyone from posting, but in some situations it makes sense to actually understand what the words mean one uses. Otherwise this is more like a metaphysical conversation where everybody projects their own hopes and dreams into magical words and is then upset when others disagree. We won’t make any progress that way.
1 Like
Would the minimized requirement not also disqualify the Librem?
I know they can disable ME using HAP, but can they actually clean ME on the Librem?
3 Likes
@renehoj sounds like they do both: minimize and disable …
While finishing our first coreboot port, we have successfully neutralized (zeroed-out) a very significant portion of the Intel ME, thanks to the great work of the “me_cleaner” project. By doing so, we remove the Intel ME’s kernel, network stack, and about 90-92% of the Intel ME binary in total (this figure varies across ME versions).
I assumed the Librem 14 would be the 10th gen CPU, their documentation is about using me_cleaner on 6th gen skylake.
I don’t think it works anymore, you can only use HAP on the new CPUs.
2 Likes
See the page dedicated to Librem 14:
No, it’s not minimized. Earlier laptop models (including mine) were neutralized as explained in your ilnks, but not the new one.
2 Likes
As far as I know, here are laptops that still get microcode updates (6th gen and later [11]) + have coreboot:
| Laptop | CPU cores | ME | EC | Qubes suspend |
|---|---|---|---|---|
| NovaCustom NS51, NS70 | 4 x Intel 11th | ? | ? | ? |
| Purism Librem 13v4, 15v4 | 2 x Intel 7th | minimizable [12] | ? | yes - see HCL |
| Purism Librem 14 | 6 x Intel 10th | factory-disabled | FOSS [5] | yes [9] |
| Starlabs Mk VI | 4+8 x Intel 12th | ? | ? | ? |
| Starlabs Mk V | 4 x Intel 11th | factory-disabled | proprietary [7] | yes [8] |
| System76 darp8 | 4+8 x Intel 12th | ? | FOSS | no? - 12th-gen |
| System76 galp5, lemp10 | 4 x Intel 11th | user-disabled [2] | FOSS [A] | no [10] |
| System76 oryp7, lemp9 | 4-8 x Intel 10th | ? | FOSS [A] | yes? - S3 |
| System76 galp3, galp3b | 4 x Intel 8th | factory-minimized? [4] | proprietary? [A][B] | yes? - S3 |
Note: Intel 11th-gen onwards dropped support for S3 sleep, replacing it with s0ix, which is not currently working in qubes.[1] Though certain Intel 11th-gen CPUs have working S3.[3]
[1]https://github.com/QubesOS/qubes-issues/issues/6411
[2]WIP: disable ME on galp5 and lemp10 · system76/firmware-open@f8c3962 · GitHub
[3]https://www.reddit.com/r/System76/comments/o19ew4/starlabs_better_than_system76_tuxedo_and_starlabs/
[4]while upstream coreboot has option to run MECleaner on these boards, Bootguard may prevent modification. Is vendor-signed firmware, ME-minimized?
[5]Librem-EC on Purism Devices – Purism
[6]Previous Models - System76 Technical Documentation
[7]Star Labs (@starlabsltd): "We appreciate the supportive feedback and we certainly are Ryker! We are looking to make this available over the next couple of months. The best suggestion we can make is to sign up to our newsletter as this will be the first place any details relating to this will be released 🙂"|nitter
[8]HCL - Star Labs MK V
[9]Hardware compatibility list (HCL) | Qubes OS
[10]https://github.com/system76/firmware-open/issues/151
[11]https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/blob/main/releasenote.md#microcode-20220510
[12]Coreboot Firmware on Purism Librem Devices – Purism
[A]System76 open boot firmware / EC list: System76 Open Firmware Models - System76 Support
[B]System76 ec boards: ec/src/board/system76 at 60dfb62f90e039c9aa73eb15d71a56b4d00a02d5 · system76/ec · GitHub
6 Likes
Is there any reason why this model couldn’t become at least a candidate for a recommended laptop that works well with Qubes (check under “System Management”)?
Is there any reason why this model couldn’t become at least a candidate for a recommended laptop that works well with Qubes (check under “System Management”)?
It’s all documented:
So let’s look:
- there is not a single HCL report for this machine
- it runs Alder Lake (12th gen) … there are only 4 HCL reports for this generation, 2 of which show issues
So the only way this machine would be a candidate is if at least two community members buy it and submit HCL reports confirming that “Qubes OS installs without any workarounds” and “Graphics, networking, audio & suspend work without troubleshooting” … which frankly is extremely unlikely (especially the suspend part). Alder Lake is just too new.
3 Likes
Thanks for elaborating. I wasn’t specific enough. I meant something more like - potentially promising
Soo, I asked this question several times and got no answer: what is the recommended hardware if I want to get the most smooth experience on a 5k2k monitor?
I do not care much about firmware blobs or disabling Intel ME, I just want a desktop that would not be a disappointment.
I already asked for some more precise recommendations or just personal experiences in multiple places but all answers I got were vague at best.
Would intel native video be the best or are there better video cards? Are there issues with latest generations? No idea.
At least i hoped someone would say “it is my config and it works truly great!” but there was not a single answer like that even.
My current desktop is nuc10i7 and it is definitely not a performance monster. I have a strong feeling that if I upgrade my “4x1.5k” ultrawide to true 5k2k, it would suck, if it would handle this resolution at all which I am still unsure and no one confirms so far.
I’d like to have this one, without asking anyone anything.
How I see it, it’s mostly about CPU when it comes to Qubes. And i7-12800HX looks like a beast for a fair price.
1 Like