I use a dedicated machine. It’s not recommended to dual-boot Qubes because even if the Qubes install is encrypted, /boot isn’t. A second OS can modify it and compromise Qubes before it loads.

Sharing hardware also means the other OS can tamper with BIOS/UEFI firmware, which puts the entire system at risk.

Anti Evil Maid can alert you if /boot was changed, but it can’t prevent it or undo the damage.

It’s also recommended to buy new hardware if you’re serious about security. And if you’re looking to run QubesOS on a dedicated machine, the hardware compatibility list is your friend. With Qubes, newer doesn’t always mean compatible.

It should be noted that the unofficial community-recommended hardware list is for 4.1, and we are on 4.2.4 with 4.3-rc3 already released for testing, but you can find good recommendations and answers on the forum.

https://doc.qubes-os.org/en/latest/user/hardware/system-requirements.html#choosing-hardware

https://www.qubes-os.org/hcl/

https://doc.qubes-os.org/en/latest/user/hardware/certified-hardware/certified-hardware.html

https://forum.qubes-os.org/t/5560

Reply to this note

Please Login to reply.

Discussion

Isn't the BIOS/UEFI firmware closed source? Meaning the attack vector is by intelligence agencies being allowed to install their blobs into the image pre signing?

Put code in boot sector to change BIOS settings, undoes any security for a backdoor.

Some BIOS can be locked with a pin code.

Thank you for taking the time to give such a thoughtful answer.