The list of “obscure” hardware I’ve managed to get Qubes OS running on, in some form:
MacBook Air A1369 - Qubes 4.0.3 (no versions newer than 4.0.3 seem to even boot)
GPD Win Max (Intel i5-1035G7) - Qubes 4.1-rc1
GPD Win Max (Intel i7-1195G7) - Qubes 4.1-rc1
GPD Win Max (AMD Ryzen 7 4800U) - Qubes 4.1-rc1
MacBook Pro A1278 - Qubes 4.0.3 (no versions newer than 4.0.3 seem to even boot)
MacBook Pro A1706 - Qubes 4.0.3 (libxenlight didn’t play nice)
iMac A1224 - Qubes 4.0.3 (Apparently nVIDIA used to make ethernet hardware… )
Intel NUC 10 (Intel i7-10710U) - Qubes 4.1-rc1
Planned hardware (pending budgets)
RockPi X (Intel Atom x5-Z8350 Cherry Trail)
LattePanda Alpha (Intel m3-8100y)
LattePanda Delta 432 (Intel Celeron N4100)
ODROID H2+ (Intel Celeron J4115)
UP-Squared (Various Intel)
Udoo X86 Ultra (Intel Pentium N3710)
ASUS ZenFone 2 (Intel Atom Z2580)
The biggest headaches are:
RAM (or lack thereof)
Having 4GB of RAM means you can basically only run sys-net, sys-firewall, sys-whonix, and ONE AppVM at a time. It’s fun trying to do Template upgrades when you haven’t got enough RAM to start them!
I have spent weeks getting Qubes OS to boot to an XFCE desktop on certain machines, only to realise that the CPUs are vulnerable to Spectre and Meltdown (mostly because Intel just never released microcode that fixed the vulnerabilities). So, does it work? Why yes, indeed it does. Would I use it in any production environment? Probably not…
Apple’s BIOS/EFI (the thing that makes the hardware go “DUUUUUNNNNGGGG!!!” when you press the power button, whatever you want to call it)
Anyone who’s interacted with Apple devices knows that their bootloader is very picky. Getting Linux to boot on Apple hardware will usually involve “tricking” the Apple bootloader into thinking that it’s booting MacOS. The problem is, it will also grab some PCI devices (especially the wifi card), and refuse to let go, even after booting. This causes a massive kernel panic and system freeze (the cursor stops moving) if you try and pass it through to sys-net. It took me six months to find a workaround… Six months of a MacBook Air with no wifi…
Hardware Circuitboard Design (How the ports are connected and grouped together on the motherboard)
Apple hardware is particularly frustrating when trying to get Qubes OS to work. Because you have to pass through the entire PCI device, you have to give a VM everything that is on that PCI device. For most Apple hardware, the internal keyboard, trackpad, camera, and SD card reader will be hardwired on the same USB bus as one of the USB ports (or both of them). This means that if you try and pass a USB port to an AppVM (USB game controller, webcam, network adapter, or anything that isn’t a block device), you lose the internal keyboard and mouse as well .
I’m sure there are other manufacturers that do this, too, though…
Qubes OS (currently) only runs on x86_64
I have no doubt that one day Qubes OS will run on other architectures (ARM , and I wish I could help out with that), but for now, you’re stuck on good ol’ x86.
On another note, this would be an interesting video series.
"Can it run Qubes OS? could become the new “Can it run Crysis?”
This reminds me: with Intel introducing performance and efficiency cores into their x86 CPUs, and with this looking to be the norm from here on out, are there plans for Qubes to take advantage of this feature?
ALL x86 chips are vulnerable to SPECTRE and MELTDOWN on some level, unfortunately.
They don’t know all the vulnerabilities yet, because they’re still finding them (and fixing them as they find them, so no need to panic).
They don’t appear to be vulnerable to any of the CVEs logged so far, which is good.
Honestly, the only gripe I have with it is the fact that it’s got soldered RAM 16GB is enough for laptop use, but I wish it was upgradeable. I wanted 64GB+
The BIOS can also be reflashed if you like (I’m still working out the specifics of this, but I’m sure someone out there in the world has already figured this out).
Other than that, Qubes OS does need a little tweaking to get some things to work (dom0 didn’t have alsa-sof-firmware installed, the display has a weird resolution you have to configure, etc.) but nothing too difficult if you’ve been in the Linux world for a while.
The main reasons for getting them were:
It’s about the size of the book/warranty/manual that comes in that leather case in the glove compartment of a new car (20.7cm x 14.5cm x 2.6cm), which means it’s small enough to carry in a shoulder bag. It’s a chunky beast, but that also makes it a viable self-defence weapon in an emergency
I love having many ports (especially an Ethernet port!)
Intel AX200 as standard (Wifi 6!)
M.2 slot for the SSD (upgradeable!!!)
Built-in Xbox 360 controller (wired into the second USB bus, works great with Qubes passthru), which also doubles as a “cursor nipple” (the quintessential red joystick that’s between the G and H keys on a ThinkPad), which is kind of cool.
I love showing up to meetings, pulling it out and watching people start comparing it to their laptops, and then I say “this tiny little thing is probably more powerful than all your machines combined”
All models needed tweaking to get the display to work:
The AMD Ryzen 7 4800U model runs Qubes OS 4.1-rc1 great out of the box….so far….
The Intel i5-1035G7 model needed a few kernelopts passed to sys-net to get the wifi card to work, but everything else works great.
The Intel i7-1195G7 model needed the display rotated, as well as alsa-sof-firmware to be installed in dom0, and I’m also trying to fine-tune the display (and learning how to navigate xrandr as I go)…
There is a version of Xen that has been written for the Raspberry Pi 4, so there’s definitely progress being made.
That’s a really cool idea. OS developers having links to ISOs, VirtualBox images, and Qubes OS Templates in the Downloads section of their websites. Maybe one day…
I definitely know that a specialised version of Qubes OS that was basically like a server, and Qubes OS workstations would be able to host their qubes on that server, and they’d show up on their local Qubes OS machine like regular qubes; would get a lot of interest from the enterprise world.
Xen might not even be necessary, since distributed Qubes wouldn’t need virtualization as intra-qubes communication would be handled via SSH (if I remember correctly). If RPi supports Xen, it wouldn’t hurt too much to add a layer of virtualization, I guess.
This gives me a half-baked idea though. What about Fractal Qubes? The basic idea is as follows: An internal, cloud-based Qubes, where the company’s entire infrastructure is hosted on one massive Qubes OS, which is then split into multiple smaller Xen instances, each its own Qubes OS. The admin Qubes of course has its own sys-net, sys-firewall, etc. to protect against compromised ‘branches’. Sysadmin becomes a breeze with Salt. Might be a boon for the project’s revenue generation.
Biggest weakness: Single point of failure (Xen), but that single point of failure isn’t too different from most (monoculture) networks?
Yeah, still. If you’re dealing with critical information, you probably don’t want any IT/IS guy in your org to have admin.
25+ years ago I was an intern at a large global company you would recognize. I was barely allowed to drive a car, but I had the admin password for the entire domain and every computer on it, the keys and combination to the safe room (backup tapes) and the access to the “shutdown the whole plant” button.
That was cool but even back then I also realized how absurd this was.
Unless it’syour own cloud of course. Let me quote Joanna:
Readers who are allergic to the notion of having their private computations running in the (untrusted) cloud should not give up reading just yet.
…pretty sure I expressed my interest when the announcement was made. Having my own Pi’s or corebooted desktops hosting qubes … locked down, locked away and with temper detection.
When hearing “cloud” or “corporate install” I think of having someone else’s fingers in my stuff, which I solved by locking THEM into a qube. There THEY can administer/scan/monitor until the cow’s come home – I don’t care.
I have bad news to report. I have opened up the laptops and looked at the board, and discovered that GPD appears to have done the ol’ switcheroo on us. The original model (i5-1035G7) does have an Intel AX200 module soldered to its board, capable of Wi-Fi 6 (802.11ax).
However, despite every single piece of advertising I can find on GPD’s website, the 2021 models (i7-1195G7 and Ryzen 7 4800U) have an Intel 7265 module soldered on, only capable of 802.11ac.
They are still very good machines, however I am a little frustrated (actually, VERY frustrated) about this. It was one of the main reasons I went with them.
I cannot figure out why they would do this. Either they compromised due to pandemic manufacturing shortages, or they were dishonest. Either way, it kind of sucks…