Sharing my checklist for buying a laptop to install Qubes

Several years of using Qubes OS and installing or attempting to install it on multiple laptops, I share hereafter my personal checklist of what to avoid and what to look for when buying a laptop to install Qubes OS on. Any feedback or correction is welcome as this is for learning and can evolve.

Things to avoid

  • Intel vPro/AMT. * Some Lenovo Thinkpads allow you to disable AMT in BIOS.
  • Elaborate BIOS. I tested once a cutting-edge HP business laptop are, but in order to get the Qubes OS installer starting, I had to work through the elaborate BIOS, disabling a lot of “things” at random. And I did not continue the attempt.
  • NVIDIA / AMD graphic card. With dedicated graphis cards, Qubes OS may not boot or install. In one case of a high-end Lenovo Thinkpad, I had to disable graphic card switching and keep the graphic card NVIDIA at all time, resuling in permanent heating and the need to keep the laptop plugged to power. The battery couldn’t keep up with the graphic card and the laptop shuts down.
  • 4k laptop screen. Qubes OS is not the best for high-DPI, or for switching between 4K laptop screen and Full HD external monitor. I recommend 1920x1080 laptop screens or similar.
  • Latest laptop models. I suggest a one or two year old laptop. The current version of Qubes OS may not boot on the newest model. For example, in 2019, I had to wait until 4.0.1 was out for it to install Qubes on a laptop that just didn’t boot on 4.0. In some cases, the microphone and/or camera did not work because Linux drivers or Qubes OS Dom0 drivers haven’t caught up.

Things to look for:

  • 32 GB RAM and Core i7
  • Ethernet port, because if your threat model requires you to use Qubes OS, then you would want to avoid WiFi. And an Ethernet port is better than connecting a USB Ethernet dongle to sys-net (to keep PCI devices isolated? I read something similar somewhere).
  • At least two USB ports in addition to USB-C. A large usable trackpad. And and HDMI port. The less peripherals (mouse, USB-C dongles) the safer.
  • Extra-Large battery. Most premium high-end laptops have cut battery size in an effort to reduce weight. On my super slim and very portable laptops, the battery lasted an hour while using Qubes. On a slightly bigger laptop with more ports and a bigger battery, the battery lasted at least 3 hours (instead of all day if using Windows on same machine)
  • Ability to update BIOS via USB (.cab file for a self-updating BIOS or an ISO bootable USB), without giving tbe BIOS internet access and without needing live boot or dual boot. Laptops regularly update their BIOS, sometimes with severe vulnerabilites. You cannot perform BIOS/firmware upgrades from within Qubes. Some vendors provide for updates only via Windows or Linux. This is to avoid. I was disapointed to read that system76 BIOS update requires POP OS. These are some posts of how challenging firmware update can be:
    Updating the firmware when using Qubes
    What is a suggested way of updating BIOS firmware?
    HCL - System76 Darter Pro (darp8) (2)

I don’t necessarily agree, for the reason explained here:

In other words, just because you can update the BIOS offline via USB doesn’t mean it’s automatically more secure than an online update, since some update blobs distributed for offline flashing via USB can’t be authenticated in any meaningful way, whereas some online update methods can be. If you download an unauthenticated blob, copy it onto a USB drive, then use that to flash your BIOS, you’re still accepting the insecurity of “online updates,” just with one or two extra steps in between (physically moving a USB stick around and copying some files onto it) that do nothing to improve security.

Thanks @adw for your reply!
Is verifying the SHA256 “authentication” with the extra precaution of reading the SHA256 on two different machines?

Sorry, I don’t understand the question. Perhaps you could try rephrasing it.

Sorry for the lack of clarity. What I meant was that BIOS update files have their SHA256 checksum available. For example, the BIOS Update ISO Bootable CD here has the “view checksum” > SHA256 BIOS Update (Utility & Bootable CD) for Windows 11, 10 (64-bit), Linux - ThinkPad T490s, X390 - Lenovo Support US

If we verify that the downloaded file SHA256 checksum corresponds to the online one, viewed on two different machines, would that be meaningful authentication, or would you still consider that “offline flashing via USB can’t be authenticated in any meaningful way”?

Wouldn’t boot guard make it impossible for anyone but Lenovo to make firmware for the T490 and X390?

I could be wrong, but I don’t think you need to verify the firmware. The verification is done at boot time, if the firmware isn’t signed with the official key boot guard will prevent the system from booting.

Ah, I see what you’re asking now. I would regard that as better than nothing but not meaningful authentication, because an attacker could modify the hash values displayed on that website or whatever version of it that your two computers see (e.g., from a CDN or cache). An attacker could also use DNS cache poisoning and various other attacks. Using two different machines to check the same website does not guarantee that they don’t just both see the same forged hash values, especially if they share the same IP address. Checking via different network connections (e.g., clearnet, VPN, Tor) would be a bit better, but it still wouldn’t address the fundamental problem, which is that you have no real way of knowing whether those hash values are authentic. You’re just hoping that they weren’t replaced at some point in between the genuine issuer sending them out onto the Internet and you receiving them from the Internet. That’s why security-conscious organizations use end-to-end authentication (e.g., via PGP signatures) to allow things like hash values to be strongly authenticated.

That would be wonderful, but I have no idea whether that’s the case or how one could go about finding out whether it’s the case.

I know the intelmetool from the coreboot/util will give you detailed information on the state of boot guard.

Using rdmsr should also work

sudo modprobe msr
sudo rdmsr 0x13a

#define BOOTGUARD_DISABLED 0x400000000