During the installation, Qubes provides a number of options for the user based on their level of acceptable risk. For instance, you can use sys-net as sys-usb in a single VM, you can whitelist mice by default, sys-firewall and sys-usb can be made disposable or not, fullscreen mode can be enabled, etc. These are convenient settings that make Qubes more user-friendly from the start whilst sacrificing a degree of security.
People have different use-cases for Qubes. Some people are using it for the most hardened OS possible. Others use it just to keep their business and personal lives separate. Some are using it for development, security research, or even pen-testing.
I know that it is impossible to cater to every need, but I think there should be a few more options provided. For instance:
Disable microcode mitigations and other options to improve performance
Enable VirtIO GPU extensions once Xen 4.18 is released to provide GPU acceleration to guests
I can hear the screaming already - “THAT’S NOT WHAT QUBES IS FOR! SECURITY RISK!!!”
I’m going to push back. If the philosophy behind Qubes is all about hardening above all else, the current options would be removed because they compromise security. However, they were added to simplify the system for those who are willing to accept more risk. Why are these other configurations any different? Are they considered more risky? Perhaps, but that’s your opinion. Some users may have a different perspective.
For me as a developer, I am all about getting the most performance I can out of my aging hardware, so I disabled microcode mitigations in 4.1. However, my system is pretty slow in 4.2, and I can’t figure out why. It shouldn’t be required to read dozens of blog posts, issue reports, PRs, etc. to improve the performance of my system (and still have it be slow as molasses).
When Xen 4.18 is released, I believe that will simplify GPU sharing to guests. Is this a security risk? To some, yes, but to many, this risk is minimal compared to performance gains. It shouldn’t be necessary to recompile xen-vmm and install a custom kernel to allow this to work.
Again, I know it is impossible to provide options for every user and their use cases, but there are many configurations that are frequently requested. I think it would be helpful to simplify these during installation so users don’t spend multiple hours scouring the internet for a solution.
I think the non-screaming version might be something like this: There’s nothing wrong with what you want. Your desires and use cases are legitimate and understandable. But why should one tool be made to serve so many different masters? Isn’t it better to have a variety of tools, where each one does one thing and does it well?
Qubes OS is a tool for securely compartmentalizing one’s digital life. It accomplishes this by being a reasonably-secure, single-user desktop operating system. It does that one thing and does it well. It doesn’t do high-performance computing well. It doesn’t work well as a network server. It can be made to do such things with enough finagling, but it’s a bit like jamming a square peg into a round hole.
Should Qubes continue to focus on doing one thing and doing it well, or should it try to take on more jobs and risk doing them less well? In my opinion, it should stay focused on its primary function. Security is hard enough. If Qubes ever fails to be significantly more secure than more mainstream operating systems, there will be little reason to use it. It’ll just be a more cumbersome, less capable version of them. I don’t think Qubes can afford to be distracted if it is to succeed in its mission, especially since it is a small project with limited resources.
It’s not as though all options that sacrifice security for functionality are on equal footing. For example, some computers cannot run Qubes at all without certain accommodations. Making some security sacrifices in order to be able to run Qubes can actually increase overall security, because the alternative is having to run a completely different operating system — one that will almost certainly be less secure. This is decidedly not the same thing as sacrificing security for the sake of performance, convenience, or fancy features, because those things are not required in order to use Qubes for its intended primary purpose.
I think the main difference between the current options that sacrifice security and the ones you’re requesting is that the current ones are mostly related to basic functionality that is required for Qubes OS to work as intended on a lot of hardware. Let’s look at the specific examples mentioned:
My understanding is that this is required for computers that rely on a USB device for network access. Without this option, the computer cannot have network access at all. While it is possible to use Qubes on a completely-offline machine, I think it is reasonable for the developers to consider network access to be a basic requirement for the vast majority of intended use cases.
On some computers, the only possible way to have any kind of pointing device is with a USB-connected mouse. Again, while it may be possible to use Qubes with only a keyboard, I think it is reasonable for the developers to include a pointing device in the baseline functionality they’re targeting.
I’m not entirely sure about this one. Up until relatively recently, these qubes being non-disposable was the default. Maybe it’s still being phased in, or maybe these being disposable still causes problems for some machines. (Note that the remarks above about network access and pointing devices may also apply here. If either of these qubes were unusable, basic functionality would also become unavailable.)
This one is different. For one thing, enabling full screen mode does not have to reduce security. If you are careful, you can always check to make sure that a full-screen window is not impersonating dom0 (e.g., using a keyboard shortcut that’s intercepted by dom0 to move/switch/display windows). For another thing, this only affects qubes for which full-screen mode is enabled, which means it has no effect on security when, e.g., those qubes are shut down. The security impact really depends on how the user chooses to interact with this feature.
Now, let’s turn to consider the requested options:
I’m not sure, but I think this might already be possible with some kind of GRUB option or something. But I suppose the request is for an easier way to do it. Personally, I don’t think this would be a good use of the developers’ time, because improved performance is, almost by definition, not required for any of Qubes’ intended use cases. Of course, in the extreme case, if performance is bad enough, it can make any system unusable, but I don’t think that’s what we’re discussing here. We’re just talking about being able to do all the same things either somewhat faster or slower, but still within usable parameters.
I don’t know enough about this to comment on it.
I also don’t know anything about this, but it’s worth noting that qubes-remote-support exists. From my personal perspective, this seems almost antithetical to the purpose of Qubes. I’m trying to do everything I can to keep people on the network out of dom0 and my offline qubes, not open up holes to let them in, so this seems counterproductive. But then again, maybe there are secure ways to do this and legitimate use cases that I haven’t considered, so I’ll reserve judgment until I learn more.
My understanding is that giving a bluetooth keyboard access to dom0 would make it significantly easier for the entire system to be compromised. If there’s no other keyboard option besides bluetooth, that might be an acceptable risk (since the system would be unusable without a keyboard), but as far as I know, there are no Qubes-capable devices that support only bluetooth for a keyboard. Again, I don’t think this would be a good use of precious developer time for the general reasons discussed above.
A bluetooth mouse might be more acceptable, given that (1) mice are less security-sensitive than keyboards; (2) USB mice are more commonly granted access to dom0 than USB keyboards; and (3) wireless mice are extremely common (especially with laptops) and could eventually come to displace wired mice in the computing market, at which point some users may have no other choice.
My understanding is that bluetooth headphones can already be used in Qubes. See these related threads:
Wow! Thanks! Anyone agree or not with your points, this should be pinned at some top. I bet it would be easier to decide for oneself after reading this.
You raise some good points, @adw, and I tried to address them in my OP with the blanket statement that I understand Qubes can’t and shouldn’t be everything for everyone. However, providing expanded flexibility is good for any system as long as the risk and risk tolerance are acceptable.
This is probably too long, but let me bore everyone with some definitions. A rough definition of risk is a vulnerability’s severity vs exploitability. A vuln can be:
High severity, high exploitability
Low severity, high exploitability
Low severity, low exploitability
High severity, low exploitability
The first two categories would be considered “high risk” by pretty much everyone. The first category are extremely dangerous vulns that are easy to exploit, and it is unwise to not mitigate them (Heartbleed would be a good example). The second category are more like “low-hanging fruit” - vulns that aren’t that serious, but they’re easy to exploit, so . . . patching them is a no-brainer.
The last two categories are where things are up to debate. Even if a vuln is severe, if it isn’t easily exploitable (i.e. it requires physical system access or some Stuxnet-level worm/rootkit to be exploited), the risk may be acceptable. These are your, “What are the chances?” vulns.
With these categories defined, let’s consider risk tolerance/acceptance. A rough definition of risk acceptance would be the cost/benefit analysis of mitigating the risk. Do you gain anything from not mitigating the vuln? If not, patch it. If there are substantial gains, perhaps it is worth considering not mitigating the risk.
In most cases, configuration options provided by Qubes should be vulns that are in the last two categories but provide enough of a benefit to optionally not mitigate them. There is a lot of room for debate, here.
TL;DR:
I suppose my recommendation is actually twofold:
For low-risk vulns that have enough benefit and demand, consider mainlining the option to enable/disable the mitigation (as long as it is possible and practical to do so)
For high-risk vulns that have enough benefit and demand (or vulns that don’t have a practical or possible method for easily enabling/disabling them), consider providing formal documentation.
I think there are a few options that should be considered for the first list. Examples would be providing a way to enable/disable microcode mitigations (and whatever else is needed to fix performance*) and in the future, the ability to set up shared GPU resources via VirtIO. These vulns are both highly severe yet difficult to exploit, but they also provide huge benefits in terms of performance. So, it is reasonable to make the option available to the user. At the very least, provide documentation until they can be added as configuration options.
The second list would include things like Bluetooth devices. These vulns are severe and easy to exploit, but some might be willing to accept this risk because the benefit of a wireless keyboard and headphones may be worthwhile. Enough users have asked for this that it should probably be added to the formal documentation instead of being spread throughout the forums.
So, I suppose this thread is a good place to suggest additions to these two lists. Thoughts?
*The performance issue is one of the main reasons I started this thread. In 4.1, a simple GRUB flag disabled microcode mitigations and restored performance. This could easily be added as an option during installation. However, in 4.2, my system is still a sloth after applying GRUB flags. Worse, there isn’t any good documentation to help me figure out. I would really like to see an installation option or documentation to help fix this issue.
In the future, I would add VirtIO/GPU sharing to this list. Multiple monitors are extremely useful, but Qubes doesn’t have good GPU support. In Xen 4.18, VirtIO should allow shared GPU access. This is risky because of shared memory between VMs, but GPU acceleration is an enormous benefit. For those who use multiple monitors, this would be worthwhile.
I think these are reasonable recommendations. The main challenge would be figuring out where to find the resources required to achieve them.
The first one sounds like it would require time from developers who are experts in the sort of virtualization-based security that Qubes uses. These experts seem to be scarce and in high demand, and those who are already working on Qubes are already maxed out working on core functionality that is critical to Qubes’ primary mission. I think taking them off that work to work on optional stuff would be a mistake in the long run. However, I can imagine that there might be members of the Qubes community like yourself who have the requisite skills and are personally invested in making this happen. Perhaps they could contribute code to make this happen. This work could be funded by the project, by a benefactor, or even crowd-funded by others of the community, like yourself, who are also invested in this outcome.
The second case is similar. The type of advanced documentation you’re describing requires subject-matter experts. Of course, the core Qubes developers themselves are SMEs, but again, their plates are already full with critically-important work, and I think distracting them from that work would be a mistake. Besides, much of Qubes’ core functionality still isn’t documented, so if they’re to spend any time writing documentation, that should come first. As in the first case, I think the best hope here is probably for a SME from the community to contribute the documentation. Again, this work could be funded in one of the ways described above.
I wanted to first thank everyone by being so receptive and positive, here. With so many projects, the response is, “No, we’re not doing that - kthanksbye.” I appreciate the encouraging feedback.
Fair point. I’ve been an active Qubes user since 2016, so I agree that it’s long past time for me to give back a little. My only hangup is that many of the things I think should be documented are things I haven’t completely figured out.
Bingo. This is where I fall short and one of the other reasons I posted. I would be happy to provide some documentation, but in many instances, I’m at a loss. I often find myself chasing down forum posts and open issues on GitHub without finding a working solution.
Perhaps this post can be used to collect feedback and ideas of what users would like to see documented. Then, those ideas can be put to a poll to prioritize them. Those at the top can be considered for actual implementation and not just documentation. Is that reasonable?
Ideas would need to be things that are possible and practical to be implemented in Qubes and have a big enough use case/user base to demand inclusion (even if risk is involved - risk should be documented, not altogether avoided).
Off the top of my head, these are some of my top “issues:”
Performance tuning
How to disable mitigations via GRUB, what other settings are available in 4.2 vs 4.1, etc
Lots of good info here, but I can’t figure out why 4.2 is so much slower than 4.1 - I’m missing something
GPU acceleration
How to compile Xen (or how to enable) VirtIO GPU once Xen 4.18 is available
List which cards are known to support passthru and how to get them to work (if other steps like recompiling Xen are necessary)
Other less-secure methods that may work (while noting their severity and exploitability)
Sometimes there are posts about this subject . To loose QubeOS for easier usage. Like this . or this one from me
I use Qube just for fun. I have no risk from my professional activity and I have relatively good digital hygiene habits to keep me out of 99% of privacy or security threats (seriously qubeOS will not help you if you mess around) .
I was thinking about the same in case of installation.
I only can note that till Qubes team is not big they have limited resources probably. My opinion was to create some tools which would allow mitigate many uncomfortabe things from qubes. Probably it’s not possible to change microcode something but bluetooth would be easy change.
Here some of my ideas. Like if user don’t need strict security then they explicitly cross the “don’t install nothing to dom0” line BUT once and then they customize qubes as they want.
From other side: A I mentioned in this comment the team has limited resources. If qubes would be easier in some things like “bluetooth” and others. Then I assume more people could use it and more resources were available what would be invested in even more security edge cases or whatever performance
I can sympathize. I’m afraid I don’t know of a good solution for this.
Sure, that sounds useful. I don’t think that the result would be binding in any way on the Qubes devs, but certainly presenting them with the strongest case (backed by a poll from the community) is most likely to persuade them that it’s a worthy cause. Also, this could be used to start a community effort, possibly including funding community devs to take on the work.
This is very well said. However some of the things mentioned by @summersab look more like the former case to me rather than the latter. For example, optionally allowing GPU acceleration in appVMs would allow people working with GPUs to use Qubes as their daily driver. Without such option, they have to run a completely different operating system, decreasing their security, as you said yourself. Same with the microcode mitigations, for people who need a lot of CPU power (however this AFAIK more drastically harms the isolation, so it’s debatable).
I haven’t commented specifically on GPU acceleration, both because I don’t know much about it and because I’ve seen things that suggest it might be planned for Qubes at some point and in some form.
It sounds like you’re saying that everyone who wants to use Qubes should be able to do everything on Qubes that they currently do on non-Qubes OSes, including high-performance use cases like gaming and training AI models. While that would be nice, it’s again a question of how to prioritize different goals under conditions of scarcity. It’s not necessarily Qubes’ fault that some people have to choose less secure OSes because they want to do things that can’t be done in Qubes. The question is whether those things fall within the scope of what Qubes aims to do (and what that scope and aim ought to be).
Just because someone “needs” to perform a certain activity with their computer doesn’t mean that activity qualifies as basic functionality that Qubes should be expected to deliver. It’s reasonable for the Qubes devs to target or prioritize use cases like having a working pointing device, having network access, running a word processor, running a spreadsheet, and running a web browser; while excluding or deprioritizing use cases like running AAA games and training AI models. The former are clearly more basic and fundamental than the latter.
I think there is a definite “happy medium,” here. People who want to game on Qubes are really stretching the boundaries of what Qubes was designed to do. (As for me, I don’t game, I don’t consider it to be a professional or necessary activity at all, so I don’t personally think it is worth the team’s efforts to support such a setup).
However, those who want to do things like use multiple monitors, have lots of open browser tabs, and do web development should be able to feel comfortable on Qubes. I don’t think it’s unreasonable or beyond the realm of possibilities to make this possible.
I think we should do a few things:
Get a list of realistic feature requests and get user feedback to prioritize
Add to or Improve the existing documentation
Where possible, submit PRs (or politely petition the dev deam) to make the implementation of these features easier
You can do that in Qubes OS already, it works out-of-the-box.
I’m daily driving 5760x1080 split over 3 monitors, normally running 4 VMs just for browser with +20 tabs, and streaming 1080 video. I never had any issues with it, and it doesn’t require a GPU.
I could do that on my laptop with just the built-in screen. As soon as I connected two external monitors, my system resources went through the roof, fans were on full, loading new programs became sluggish, etc. I understand why, but since there are ways to fix it . . . I’d like to fix it.
Note: I’m running 4.2 rc4, at the moment, so that may be part of my problem. I installed 4.2 hoping that the GPU options would be a bit better supported (and maybe let me use virtio-gpu features, but that isn’t available in Xen 4.17).
I don’t know why you’re speaking about gaming; I never implied that we should seriously care about gamers. I said that more often than you think, work requires GPU, e.g., in graphical design, video editing, or even running modern machine learning tools (not necessarily developing them).
I brought up gaming not because anyone on this thread mentioned it, but I can’t count the number of posts made about it. In fact, some of the top threads and guides about GPU passthrough have to do with people who want to game.
I don’t want to game. I cannot tell you how few s#!ts I give about gaming. I want to use my GPU so I can squeeze some extra performance out of my beefy laptop . . . from 2016. I want to use it for development purposes.
Let me do a bit more scouring around the forums to improve my “list.” If I can help it, I don’t want to just be another user screaming into the void on the forums - I’d like to actually help write some of these guides, maybe submit a few PRs on GitHub (I’ll have to brush up on my Python), etc. Time willing, I’ll be able to do so.
Only a small note to counterbalance some of the tone of the conversation on the topic of playing games. There is nothing wrong with gaming on Qubes OS!
If you can play your favorite games on Qubes OS, that’s fantastic. The important bit is to have reasonable expectations. At this point in time high-performance gaming issues are not considered within the scenarios to which official support efforts are allocated. That time may come, or not. Community Guides exist to attempt and solve some of the issues that may arise on a best effort basis, and the topic is not unwelcome as long as those expectations are clear.
In other words: some folks may be upset by recurrent heated conversations about the topic, but there is no reason why it couldn’t be discussed in a calm way, as long as we all gamers and non-gamers keep our expectations in check.
Oh, I definitely agree - I didn’t want to sound so harsh in my response. I just know that there are a LOT of people posting about gaming on Windows via Qubes, and while there’s nothing wrong with that, I definitely don’t think it’s a primary focus or use-case. Getting GPU acceleration to work for general computing and development has a far larger audience.
