QubesOS provides strong compartmentalization between virtual machines defined by the user, but it doesn't provide better protection against exploitation within those guests. Network drivers are a special case due to running in a dedicated VM. Applications and guest operating systems are just as vulnerable to exploitation. They're not hardened operating systems but rather traditional desktop OSes with a weak privacy and security model. QubesOS similarly doesn't provide any significant protection against data extraction in the After First Unlock state. It's nearly entirely focused on compartmentalization at the granularity of a whole OS.

GrapheneOS is focused on privacy and security overall including protecting applications and the OS from exploitation in general. GrapheneOS does use sandboxing and compartmentalization to improve security. Hardware-based virtualization is one of the GrapheneOS hardware requirements (https://grapheneos.org/faq#future-devices) and is used through Android's virtualization framework. It's provided by pKVM on Pixels and Gunyah on Snapdragon. Making more use of virtualization beyond isolating system services via microdroid and running a desktop OS via Android's virtual machine management app (Terminal) is planned and being gradually worked on. It's part of what we work on overall, not the whole picture or primary focus. It will be a bigger focus over time as hardware improves to make it more viable.

Smartphones didn't have a lot of memory for virtualization until recently and GrapheneOS needs memory for other protections too. The Pixel 6 was the first Pixel with CPU hardware virtualization support and the Pixel 10 is the first with native GPU hardware virtualization support not requiring proxying to the host for GPU acceleration. Secure GPU acceleration is quite important for making it into a highly usable feature, especially on a phone, so the hardware was not ready yet and still isn't on most other devices. QubesOS largely doesn't have that available either, but laptop or desktop hardware is more powerful.

▲

fsflover 2 days ago | parent [-]

> but it doesn't provide better protection against exploitation within those guests

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.

> data extraction in the After First Unlock state

By whom? A physical attacker?

> Hardware-based virtualization is one of the GrapheneOS hardware requirements

Qubes doesn't force the user to have it. Could GrapheneOS also allow using devices which don't support it? It would make millions of people more secure, not less. And it would make GrapheneOS more popular, too. You could name it "GrapheneOS lite" if you're afraid of a false security message.

> Applications and guest operating systems are just as vulnerable to exploitation

Which exploitation? Where would it come from?

	▲	strcat a day ago \| parent [-]
		> 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.