Yikes. https://www.qubes-os.org/news/2017/04/04/qsb-29/

Xen is looking more and more as a liability. Subgraph OS which takes a completely different approach (sandboxing + hardened kernel) has a much better track record with the only vulnerability being dirtycow. Qubes has been affected multiple times due to Xen bugs in recent years: https://www.qubes-os.org/security/xsa/

@femme How does the comparison go when you account for the fact that Subgraph has a much shorter track record?
@femme I mean, Qubes has existed 5x longer than Subgraph has (five years vs. one year), so you would expect to see more reported bugs, even if you assume there's equal numbers of bugs existing and equal interest in finding Xen bugs as finding Subgraph bugs...
@covalent True, but it seems that Xen escapes are much more common than grsecurity privilege escalation despite many people looking for linux bugs (maybe more than Xen). I haven't heard of any plans of Xen to address the security issues other than addressing them one by one as they come up which isn't proactive enough imo. Hopefully the move away from PV with Qubes 4.0 will help.
@covalent The first subgraph os alpha was released in march of 2015 and has managed to not be affected by most public linux vulnerabilities (in fact all except dirtycow) as they either require unprivileged namespaces or are thwarted by grsecurity/PaX. Since march of 2015 according to the Qubes Security Bulletins there have been 17 separate issues affecting Qubes and that's not including the issues in the VMs people are running. So it looks really good for the two year old operating system.
@femme @covalent how many users does subgraph have? i find that is often more useful as a measure of "how well-audited is this thing" than the age of the project
@bcrypt @covalent subgraph os specifically I don't know but grsec has a lot of deployments (I think millions)
@femme @bcrypt Subgraph has a lot thicker layers on top of grsec than Qubes does on top of Xen, because grsec itself doesn't provide isolation. You have to build a sandbox yourself (in SG's case, Oz). So I don't think that grsec bugs are a proxy for SG bugs in the same way Xen bugs are a proxy for Qubes bugs.
@covalent @bcrypt Turns out it wasn't affected by dirty cow after all due to the sandbox policies in place is what xmux (one of the subgraph devs) just told me, after talking to spender who''s one of the main grsecurity devs. So all public linux vulnerabilities were mitigated by either using grsecurity/PaX or disabling the features (such as user namespaces) in the kernel configuration.
@femme @covalent is there a list like https://www.qubes-os.org/security/xsa/ that cover Linux vulnerabilities and if they effect Subgraph (if not, why?), also what about future use of Subgraph in qubes?
https://github.com/subgraph/subgraph-os-issues/issues/153
does it better if only Subgraph is used or not?

@e3amn2l @covalent I think it's because no one has made a nice webpage because everyone is doing something else to get the next alpha iso out as soon as possible.

It's a tradeoff between Xen bugs and the cool Qubes features like disposable VMs, anti evil maid, etc. But I think just subgraph OS is fine.
I also really like the effort they (Qubes) put into securing and documenting their build infrastructure.