I'll bite and give you a serious answer.
This is definitely a fair point. Auditable doesn't necessarily mean audited.
The only way to guage this for yourself is to dig into your system's internals.
That means looking at your kernel and understanding it. And that isn't
something that a task that most people are even remotely capable of.
With that being said, the important parts of the Linux Kernel have a *lot* of
eyes on them. Relative to their codebase, the same can be said of BSD
distributions. (Perhaps even more, due to the fact that they share a lot of
code back and forth.)
But for smaller projects that your system runs with priviledges, yeah, you're
in trouble. And you're right to say that keeping the attack surface small is
a good bet.
That's mostly an agreeable statement.
Keep in mind that a lot of the functionality of Qubes is provided through
proprietary, closed-souce Intel option roms.
...You realize that Xen is software, written by human beings, running in
ring0... right? Xen doesn't have that great of a record, either:
xenbits.xen.org/xsa/
And to take this further, not many people are running Xen on their personal
computer. The large majority of Xen users are in a datacenter, eg: AWS. Anyone
who has worked on kernel drivers knows that this shit is not simple. When you
start using Xen outside of its common environments, you're enumerating edge
cases.
Joanna got a lot of flak when she chose Xen for her idea of hypervisor based
security. And frankly, the majority of my problems with Qubes are related to
Xen and the way that it is trusted.
The idea itself is not bad.
The way that Qubes lets a user logically isolate the different parts of their
life is useful. If you regularly use Tor, I think you should use Qubes. If you
want to try and mitigate the ability of having your machine fingerprinted,
Qubes is not so bad. Doing IOMMU pass-thru to a VM for your machine's
networking makes it really easy *as a user* to be sure that you're not leaking
DNS requests, for example.
But a frontend for the sake of allowing users to logically separate their lives
doesn't rely on an "isolated" ring0 hypervisor. Not for IOMMU NIC passthrough,
and not for keeping dotfiles separated.
If you're analyzing malware, I'd be really skeptical of the idea that someone
can't find a way to break out of Xen. And if they do find a way to break out,
Xen does nothing to help you. It's all or nothing... So how is that better than
a monolithic kernel that tries to be secure in ring0?
If you look at OpenBSD, for example, they have W^X, pledge, and ASLR. If you've
studied software exploits, you should be able to understand how those make
things difficult.
The real issue that I have with Qubes and Hypervisor / Containerization as a
security practice is that it's peddled by people who see it as a magic bullet.
To loosely quote Theo De Raadt, do you really think that the people who can't
write secure operating systems can turn around and write secure hypervisors?
Systems programming is really really really hard, and people who stand on their
shoulders are blind to it.