Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Non sequitur?

GOS is not running a flavour of mainline Linux, but Android. They're nevertheless planning on moving to virtualisation as well https://discuss.grapheneos.org/d/24154-grapheneoss-roadmap-r...

For now it's as good as it gets.



Linux doesn't mean systemd, GNU coreutils, glibc, GCC, GNU binutils, GNOME, etc. GrapheneOS is a Linux distribution and supports the Linux 6.1, 6.6 or 6.12 LTS branches. 6.12 is the latest LTS branch. Using Linux is a pragmatic thing, not a positive one for privacy or security. A huge monolithic kernel written in C is not the future for a highly secure OS. Moving away from the Linux kernel is important. QubesOS exists as a workaround for the insecurity of Linux. If the OS was using a highly secure microkernel in the first place, their hardware virtualization approach wouldn't be needed.


> If the OS was using a highly secure microkernel in the first place, their hardware virtualization approach wouldn't be needed.

Do you have any statistics to show about how secure a micro-kernel is? I can't believe it can be better than this: https://www.qubes-os.org/security/qsb/


Xen itself is a microkernel. The list of vulnerabilities you've linked has a very limited scope not accounting for most vulnerabilities impacting QubesOS users. It also isn't a complete list for that limited scope. However, what you've linked shows the benefit of a microkernel-based design and why it would be best to have it beyond a hypervisor but rather inside of the virtual machines too. The vulnerabilities impacting the kernel and applications within the virtual machines are still very relevant to QubesOS users. QubesOS protects well against an attacker escaping from a virtual machine, but does not protect against an attacker exploiting the OS or applications within the virtual machines.

An attacker can do cross-guest exploits via the network too, which would not be considered within the scope of that list. As an example, if an attacker could exploit the network VM via a Linux kernel TCP/IP vulnerability, then exploit connected virtual machines from there with the same vulnerability. Network driver vulnerabilities are another way to get that initial foothold. It wouldn't be a hole in the architecture implemented by QubesOS but it would still give them control over everything that matters to the user.




Consider applying for YC's Summer 2026 batch! Applications are open till May 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: