The hypervisor problem can be solved (in theory) with secure boot configured with custom keys and full disk encryption. I don't know anyone who actually uses Qubes so I don't know how practical that solution is. Coreboot has something similar to secure boot, so even if you use an open source boot loader, this can be done.

An attacker would need to do some quite invasive hardware tampering to get a third party hypervisor to work on a system secured like that.

Furthermore, preventing hypervisor detection requires constant updates if the OS itself is configured to check for the presence of a hypervisor. There's a constant arms race going on between security researchers and cybercriminals who don't want their malware to trigger on analysts' machines, many of which use virtualization to easily reset the system back to a known, secure state. Every time malware comes up with a new method of detection your evil hypervisor needs to be patched to fake that stuff too or you risk detection next time the OS updates its detection algorithms.

This should work with Qubes quite well: https://puri.sm/posts/pureboot-101-first-boot-first-update-a...

See also: https://forum.qubes-os.org/t/verified-boot-on-qubes-a-lofty-...

I just wish Qubes had a simpler architecture, such that dom0 and the Qubes Components could be implemented in eg. Guix or Nix instead of a traditional distro. Love Qubes' desktop integrations.

What do you think prevents changing the distro in the Qubes components? AFAIK it's totally possible, see this: https://github.com/QubesOS/qubes-issues/issues/1919.

Oh, what an issue! There's plenty of context in there, and it's right up my alley. Thanks!