Comment by handedness
7 months ago
As one who has lived out of both operating systems for years, I struggle with the way you invariably make value judgments about GrapheneOS every time it comes up in a thread, based on your (justifiable) appreciation for Qubes OS. The same thing happens in reverse on the GrapheneOS forums, by the way.
Both lines of thinking are faulty, and attempting to directly extrapolate from one project to the other (in either direction) mostly only conveys a lack of understanding of both projects, even (especially?) one's favored project.
Joanna Rutkowska herself admitted that the difficult nature of trying to contain the PC hardware stack made it ultimately feel like she lost the war. Qubes OS is inherently vastly more vulnerable than GrapheneOS, in large part precisely because of their different approaches to hardware. Some of this has been mitigated by developments made since she stepped back from the project, but some of it will always remain. How to deal with this inherent conflict is not a simple matter and the two projects have taken two distinctly different approaches.
In the cases of both projects, I think they made justifiable decisions in their approaches. I use and contribute to both projects.
If you've been using Qubes OS long enough, you'll remember a time when trying to run it on anything that wasn't essentially identical to the ThinkPads used by Qubes OS devs often presented a major challenge.
GrapheneOS is a fundamentally different project in scope, and each project has a subset of users which seem unable to do anything but evaluate the other project based on the criteria set by the one they like.
"The goal of the project is not to slightly improve some aspects of insecure devices and supporting a broad set of devices would be directly counter to the values of the project. A lot of the low-level work also ends up being fairly tied to the hardware."
GrapheneOS achieves significantly more security on the hardware level than Qubes OS, in very large part specifically due to the nature of the project. It's also an infinitely simpler OS to get up and running with, on both current-gen flagship hardware and current-gen value-prop hardware available in just about any store which sells cell phones.
In addition to all that, by the nature of the respective code bases it presents a significantly smaller attack surface than a computer running Qubes OS.
Securing a single device type with excellent hardware security is simply much more viable a project than securing a broad range of devices with hardware security that is, at best, pretty terrible.
Repeatedly criticizing one project without significant familiarity with both is not just pointless, it's counterproductive to aims of FOSS privacy and security.
> In addition to all that, by the nature of the respective code bases it presents a significantly smaller attack surface than a computer running Qubes OS.
I critisize precisely because I don't understand what you're talking about. The last relevant VM escape was in 2006, discovered by Rutkowska herself. Since then, nothing could access my secrets in an offline vault VM. I would appreciate a clarification, how GrapheneOS can be more secure without reliable virtualization.
AFAIK Xen security relies on 100k LoC. And this is in addition to the virtualization. How many LoC does GrapheneOS require to provide its security? How can it have less attack surface than Xen? Developers replying to me here never provided an understandable reasoning, only keep repeating that it's "very, very secure", without even mentioning any threat model.
Doesn't GrapheneOS rely on closed Google's hardware to provide its security? I would never trust Google with that. How can I not critisize such approach?
Attempting to compare line counts of 'security-related code' in isolation, if such a thing can even be framed that way, as if that's a useful metric indicates a fundamental misunderstanding of the issue. Making very selective hardware comparisons while attempting to compare the relative strengths of the operating systems running on said hardware also indicates the same.
Framing closed blobs as fatal flaws while advocating for other situations also containing different closed blobs is disingenuous.
Saying no hardware designed by Google could be trustworthy while advocating for x86 architecture and hand-waving IME (or PSP to whatever degree) as being "disabled," when no such thing is fully possible, is lazy. You don't get to care about this stuff selectively. IME when disabled to our fullest ability can still receive and apply microcode updates without the user's knowledge, making access to full unrestricted PCI lanes, DMA and USB possible. Wi-Fi certainly, at least in some specific scenarios. I'm not as concerned by IME/PSP as some, though I am much more concerned by it than some others, but the consistent selectiveness of your approach to attempting to understand that (and I'm taking it in good faith that you are) is precisely the kind of thing that makes people give up on attempting to give you additional information by which to reconsider your opinion.
Citing Joanna's research without any relevant context when you find it convenient yet ignoring it when it doesn't isn't helpful, either. You raise issues, people provide relevant research, and you ignore it while accusing broad swaths of people of doing the same. At some point it feels like projection.
I don't like even the appearance of unfairly criticizing the Qubes team publicly, because it's an important yet still-fledgling-in-resources project and they're doing amazing work nonetheless, but "the last relevant VM escape" overly relies on "relevant," and you overstate Xen's security because you're looking at it in isolation as if you can compare the relative security of operating systems while selectively comparing their hardware. The Qubes OS team has allowed significant Xen vulnerabilities to remain unpatched for weeks to months, sometimes not even capturing them in their XSA tracker. The GrapheneOS team seems fairly exemplary in pushing out important patches. I say this not to knock the Qubes OS team which does great work with very limited resources, but there are real, practical, significant differences in the two approaches and so long as you're comparing specific points in isolation of their broader context you're going to miss significant fundamentals.
Qubes OS's encryption situation out of the box is lacking in numerous ways which some Qubes OS users attempt to manually address. Consider the rigor it would take one to replicate your config vs. the rigor it would take to buy a Pixel and install Graphene OS. A journalist or dissident who is massively concerned with being in possession of data, the discovery of which could see them jailed or killed, is significantly better off storing that on a device running Graphene OS. That's not a hand-wavy thing, when you consider the full stack the advantages are numerous and concrete. There are many other practical differences between the two security models, when compared holistically. File system security of GrapheneOS is miles ahead of where Qubes OS is, and it's partly due to the OS, partly due to the differences in hardware. Brute force resistance is leagues better on GrapheneOS in part because the hardware facilitates it, and the OS does a best-of-class job at taking full advantage of that hardware.
At what point will you stop repeating your line of, "I keep asking for examples but they never answer"?
I really appreciate your detailed, good-faith responses.
> Attempting to compare line counts of 'security-related code' in isolation, if such a thing can even be framed that way, as if that's a useful metric indicates a fundamental misunderstanding of the issue.
I didn't invent this. Isn't this exactly how Qubes developers frame it? Are you saying their approach is wrong? https://doc.qubes-os.org/en/latest/introduction/faq.html#wha... and https://doc.qubes-os.org/en/latest/developer/system/security...
> Framing closed blobs as fatal flaws while advocating for other situations also containing different closed blobs is disingenuous
Isn't this an important milestone, when the OS has no proprietary bits at all? This not the end, but something worth celebrating, I guess. Apart from that, doesn't Librem 5 has a lower number of blobs in general? I might be wrong of course.
> hand-waving IME (or PSP to whatever degree) as being "disabled,"
It seems you misunderstand me or didn't really read my previous posts carefully. I never considered "disabled" ME sufficiently secure. I strongly prefer "disabled and neutralized" instead, which I btw have on my laptop. It doesn't completely kill it, but it certainly makes it quite unlikely to make any harm.
> yet ignoring it when it doesn't isn't
I guess if I ignored something, I did not notice that it was relevant. Therefore I have no idea what you are talking about, i.e., which exact posts of mine you mean. If you actually want to be helpful, this is not how it's done.
> but "the last relevant VM escape" overly relies on "relevant,"
I admit that, and I specifically mentioned my threat model with passwords in relation to this. You didn't show how my threat model was wrong or not secured against.
Your other points are well articulated, although the corresponding threat model you mentioned is definitely not for everyone. Thanks again.
3 replies →