> Why would you need that if you don't run any untrusted apps in a trusted VM? Also, you don't have any private information in the untrusted VMs. It might only be helpful in the context of security in depth, but this barrier for attackers is much lower than the virtualization itself.

A user's web browser, messaging app, etc. getting exploited is going to result in an attacker getting their data from it and the OS. Containing it within a VM limits damage to that VM which depends entirely on how the user has split things up. It's not a substitute for protecting against exploitation of containing successful exploitation within applications or operating systems.

> By whom? A physical attacker?

It's in reference to situations where disk encryption matters to prevent data extraction. One of the two purposes of verified boot is as part of an overall approach to protecting against data being extracted from the device.

> Qubes doesn't force the user to have it.

No, it does require it. It works without extra features for properly containing devices, etc. but does require hardware virtualization support in the CPU. They do have mandatory hardware features.

> Could GrapheneOS also allow using devices which don't support it?

Without hardware-based virtualization? It could allow it, but then the functionality we build resembling how QubesOS does compartmentalization won't be available to users on those devices. There are much more important security features in our requirements than this. Hardware-based virtualization support was added there because any devices we'll support in the future are going to have it anyway since it's a standard feature on Snapdragon. We avoid adding features to the list which would rule out supporting a 2026 or later Snapdragon device. Memory tagging was an essential feature which is game changing for security when deployed throughout the OS and for apps, which is why it was added as a requirement despite Snapdragon temporarily losing it. Snapdragon had a very early implementation of memory tagging and then lost it due to their custom cores prioritizing performance and cost over security.

> Which exploitation? Where would it come from?

Remote attacks on the applications and OS running in the VMs. Alternatively, supply chain compromises or other forms of attacks against the applications, etc. These are the reasons why QubesOS is providing compartmentalization in the first place. However, it does not protect what's inside each VM from attacks against what's in that VM. It protects other VMs after that VM gets compromised. It depends entirely on the user dividing things up well and limits the damage of a compromise rather than avoiding it.

For example, if the user's main everyday usage web browser instance they use for most things get remotely compromised, then they're going to have all their logins, passwords and other data in that VM obtained by the attacker but other VMs will be safe. It's containing the damage, but it's still very bad. If someone divided up their web browsing heavily between VMs, they'll limit the damage more, but it could be one of their most important instances which got exploited.

For example, a journalist may run an email client and web browser related to their work in a VM which may be targeted, get exploited, and now a lot of their most important work related data is available to their attacker. The compartmentalization will likely protect their personal life, etc. but the same exploit could be used against their email client / web browser used for personal usage too. The exploit not being prevented leaves it open for use against their other compartments too.