Not stupid question at all. Nothing is 100% correct. Instead, you look at the attack surface, which for Qubes is extremely small: no network in AdminVM, only 100k lines of code in Xen supervisor, hardware virtualization with extremely low number of discovered escapes and so on.
This is a useless security nihilism. Xen is much more secure than anything else in terms of hole history. And Qubes relies on hardware virtualization, not software. Most famous escape from it was discovered by the Qubes founder ("Blue Pill").
The size of Linux in dom0 does not matter, because it has no network, does not run any apps and is only used to manage VMs. There is just no way for an attacker to exploit a bug there.
>formal reasoning
I hope this is the future, but unfortunately it's not the present yet.
Not stupid question at all. Nothing is 100% correct. Instead, you look at the attack surface, which for Qubes is extremely small: no network in AdminVM, only 100k lines of code in Xen supervisor, hardware virtualization with extremely low number of discovered escapes and so on.
Xen is bloated and has a security hole history. This also ignores the size of the Linux acting as dom0, that is.
The only correct answer is formal reasoning, as successfully executed by seL4.
> Xen is bloated and has a security hole history.
This is a useless security nihilism. Xen is much more secure than anything else in terms of hole history. And Qubes relies on hardware virtualization, not software. Most famous escape from it was discovered by the Qubes founder ("Blue Pill").
The size of Linux in dom0 does not matter, because it has no network, does not run any apps and is only used to manage VMs. There is just no way for an attacker to exploit a bug there.
>formal reasoning
I hope this is the future, but unfortunately it's not the present yet.
1 reply →
You test for it with rigor and incorporate new learning, just like every other engineering discipline.
There have been Qubes-breaking bugs in Xen before, and it wouldn't be surprising to see more.