[_8j50]

I'll just say that the entire point of zero-day is that you are not aware of it now and that zero-click attacks exist and also that while your selection of a product based on historical performance under scrutiny is valid, you cannot use that as evidence to claim an attack is not possible.

And again, you miss the whole point of zero-day, it is an unknown. You can create an attacker-hostile environment but you cannot make guarantees or claim a solution is best practice against an unknown/undefined.

As far as I am aware for example, spectre/meltdown or *-hammer attacks could have been used against your disposable vm to read your email vm's memory. There are also hardware attacks against radio controllers/chips that could be used to wirelessly dump memory without your interaction.

You know, I was just telling someone how I thought those scenes in movies where the hacker guy types really fast and hacks everything were silly when I started working in security. Now, I know that if he is just the guy buying/trading exploits and spent a lot of time automating stuff and setting up infra,it is indeed possible to make it all look so easy (but still, some movies/shows take it too far). Especiallu in government work, the guys using the tools are rarely the guys that develop them or maintain their infra. The guys who develop access might also be different from the guys who action objectives or work on exfil or shell management.

[fsflover]

I do know what zero-days are. And I do not solely use the historical performance as evidence for strong security.

Did you ever think that such a good performance that Xen and Qubes have is not a mere coincidence? What if I tell you that it is not just a pure luck? It just can't be luck statistically: in the Linux kernel, serious vulnerabilities are found all the time, whereas here they're extremely rare.

Let me tell you that it is actually a result of a good architecture. You know, in Xen, the trusted computing base, i.e., the code responsible for isolation and security is really small: it's of the order of 100k lines of code. In Linux it's millions of lines. Every code has bugs, it's unavoidable, but you simply can't have a similar number of bugs in 100k lines as in millions of lines. There are no "guarantees" here, just pure statistics.

In addition, Xen is very popular among big companies, so its code is constantly checked for bugs by the best people in the field. And zero-days in it are so expensive that you would not waste one on leaking personal data of people for no reason. Security is not about guarantees, it's about probabilities. And they are very small in Qubes, if you are not a big target. Even if you are, they are smaller than for any other system, thanks to the security-oriented design and reliance on compartmentalization.

Yes, Qubes is vulnerable to Spectre, Meltdown, *-hammer attacks. But it never attempted to protect the user against the hardware it runs on. It is physically impossible. Also, hardware attacks like these are exception, not the rule. And even they usually don't lead to VM escapes.