Hi, HN! This is a small project I developed for Qubes OS that allows you to spin up new Windows qubes quickly, effortlessly and securely.
Hope you don't mind the flamboyant title, but, I truly do believe that the small attack surface of the heavily minified Xen hypervisor, networking stack, GUI virtualization, and much more Qubes OS employs + the Whonix intergration implemented in this project (making it a Windows-Whonix-Workstation; thus also giving it Tor-only Internet access with stream isolation between other VMs) makes it the most secure and private way to use Windows currently available today. Those are just the two main points, besides that, there is also the fact that because everyone using this project is both having their Windows VMs set up in the same way and running Qubes OS, that greatly helps to keep the OS and hypervisor fingerprint homogeneous across all users. This effect will only grow stronger as the Qubes OS userbase increases. Lastly, if the user wishes to reset their fingerprint, they can automatically do so by reinstalling Windows with this project.
Of course, I would be happy to go into detail and answer questions about any of this.
Note that this project is the product of an independent effort which is not officially endorsed by Qubes OS or Whonix.
I didn't know about qubes before this, but Edward Snowden's testimonial hooked me.
So, qubes is an OS where each "process" is more or less an isolated Xen VM, is that a good starting point?
I have so many more questions about qubes than your project, but I've been struggling to find a good way to run Windows VMs on Linux reliably and your project looks great for that. Once I get a qubes os box up, I'll give it a try.
Qubes OS assumes that it's impossible to ensure every single application you will be running on your computer is secure. Therefore, the best way to secure your computer is to isolate all of the applications as much as possible so the exploitation of one doesn't lead to compromise of another or the entire system. Through (heavily minimized) Xen VMs is the most basic way Qubes seeks to provide this isolation. However, it goes much further than that into the networking stack, audio stack, GUI stack, and much more. This all lies on a security principle known as "security by isolation" or "security by compartmentalization".
You typically have different "qubes" (VMs) for all of your different day-to-day tasks/activities. Although, not necessarily each process.
I'm aware hardware support on Qubes has been problematic for some users. Luckily, it's looking to get a lot better with the up-and-coming Qubes R4.1 (currently on it's first release candidate). It will be shipping with a fully updated base hypervisor and kernel feature set to allow support for newer hardware.
I'm not quite sure the specifics of your hardware problem, but, feel free to file a bug on the Qubes issue tracker.
I have been wondering... Instead of exposing the hardware GPU to the appVM, would a Vulkan virtualization work? I.e., VM sees a Vulkan API that forwards calls to a dedicated graphics VM that runs them.
(I understand that getting windos to use them could be hard.)
Yes, I was wanting to try this on a spare laptop but having to trial on a bunch until one works is going to be challenging. Is there a place to find supported hardware?
I actually care very little about anything other than the network stack. If audio doesn't work, it won't bother me.
You're in luck, there exists exactly what you're looking for. It's called the Hardware Compatibility List (HCL), see here: https://www.qubes-os.org/hcl/
FWIW I've run Qubes on a few random Intel laptops years ago and it just worked on all of them. (Including on an esoteric milspec laptop which oozed hacker-street-cred at the time).
There is a hardware compatibility page with user reports.
The main thing is that, to be practical, it needs at least 16GB of RAM. With only 16GB, you will want to use the ZRAM swap driver on your linux VMs. Dunno if any equivalent exists for windos.
OK. My personal recommendation is, don't even try with a machine smaller than 16GB, and expect to need to manually apportion memory between VMs if you have less than 32GB.
This is really cool, starred right try out at a later date.
Question: what does GUI virtualization actually mean? Does that mean the OS runs windowed in your existing DE? I’m guessing that means no HW acceleration. Is it possible to selectively pass through the GPU for a KVM-esque experience?
By GUI virtualization, I was referring to the way Qubes handles receiving graphical updates (e.g. windows) from the VM and sending events (e.g. mouse clicks) to the VM. The Qubes GUI protocol is like VNC or RDP but much, much more secure: https://www.qubes-os.org/doc/gui/
No HW acceleration by default as of now. It's possible to passthrough a GPU to the Windows VM in order to get acceleration, although, you risk exposing complex hardware directly to the VM which comes with many security implications: https://www.qubes-os.org/doc/device-handling-security/#pci-s...
Note that in practice, passthrough works best with AMD GPUs; I've heard few reports of success with Nvidia GPUs.
That feature is currently in the works (officially speaking) for Windows 10; for Windows 7 it already exists (although it has of course been EOL for some time now).
However, I do recall finding a report of someone successfully using WinApps (https://github.com/Fmstrat/winapps) as well as RDP running in a Linux (GNU/Linux) qube to effectively also have Windows applications displayed on a window level. Security-wise it still holds up because that Linux qube, if compromised via the RDP connection, will lead to the disclosure of no additional sensitive information because it's only being used for that single purpose. As long as you have ample RAM to support it, this could work very well.
Does this use the default graphics drivers in Windows? I have an older installation of Win10 on my Qubes laptop, and I'm limited in the resolution I can set on the Windows desktop. I have 1440p display on the laptop, and the largest resolution is still a window that is much smaller than the screen. This is my biggest problem with the Windows VM, and I was hoping that your project might do something to address this.
I also faced this problem with the low selection of resolutions to choose for the Windows desktop with my ultrawide 3440x1440 screen. No worries, it was easily overcome with a simple modification to SeaBIOS, see here: https://groups.google.com/g/qubes-devel/c/aCCGpYysZTQ/m/4yMY...
I'm in the process of submitting a patch to SeaBIOS so it will no longer be necessary to patch this in yourself.
"Untrusted guest systems should not be allowed to use the 3D acceleration features of Oracle VM VirtualBox, just as untrusted host software should not be allowed to use 3D acceleration. Drivers for 3D hardware are generally too complex to be made properly secure and any software which is allowed to access them may be able to compromise the operating system running them. In addition, enabling 3D acceleration gives the guest direct access to a large body of additional program code in the Oracle VM VirtualBox host process which it might conceivably be able to use to crash the virtual machine."
You could say the Same about non IOMMU CPU virtualization. The problem here is AMD and Nvidias disgusting greed that has held back security by at least a decade. GPU virtualization (vGPU/MxGPU) is supported but only if you pay ridiculous enterprise licensing. This should be a first class feature like VT-d and would enable a usable Qubes desktop and Microsoft's VBS.
Wow, I was unaware such hardware virtualization extensions currently existed in such mature form for GPUs. Really unfortunate that they've been lost to the avarice of two tech giants which have a duopoly over the GPU market.
They're not that mature software wise due to the fact that hardly anyone uses them. Microsoft may save us here because Virtualization Based Security has to be enabled to sell an OEM PC with a Win11 sticker. Doing GPU virtualization in software has a big performance hit if not hardware assisted (like CPU virt). Hopefully this will twist enough arms at AMD/Nvidia that they will be forced to open up virt features on consumer cards. I asked an Intel graphics rep if virt would be supported on Intel's new discrete parts (Arc series) and they said wait until launch to see which is at least better than last year when they told me they had no plans.
Awesome work Elliot, and much appreciated. I've just got Windows-10 ltsc working on qubes 4.1 with whonix 16. My 2 use cases are:
1. A dev machine. I have a persistent and static disposable version of this build.
2. An anon build connected to whonix. Again, I have persistent and disposable versions.
One thing I had to do was compile the QWT v4.1.65 iso and install the resulting msi. Other than that it all works flawlessly and provides great peace of mind for those occasions when I have to use Windows.
Thank you! I'm glad to hear my project is working well for you on the upcoming Qubes R4.1 (currently untested by myself). To the best of my knowledge, no official QWT build exists yet for R4.1, so yes, building it yourself is the way to go for now. Also, good to know QWT is fully operational on the latest version of Qubes.
Qubes supports VM suspension so if you wanted to you could easily create a simple shell script to suspend and resume upon the Windows VM window becoming minimized and reopened. You could use `xprop -spy <window_id>` to check the window status without polling and `qvm-pause`/`qvm-unpause` to suspend/resume the VM.
While the suggestion does not encroach inside the Windows’ VM to perform “their” CPU suspension, it is a better idea to process suspend the host’s KVM underlying that Windows VM. Hope that the guest’s video driver doesn’t leave its hardware in an inconsistent state for the host’s main video driver and its entire system.
This tidbit needs to be made a prominent FAQ on Qube website.
I hope to try qubes one day, it's a shame that my current hardware isn't supported. If I wanted to learn how to add support for my own hardware where would I start (would probably be quite an undertaking, but might be worth learning about regardless of how far I'd get).
I'm not sure the exact details of your hardware problems but you may want to try out Qubes R4.1 when it's released (or the RC1 version now). It will ship with a fully updated base hypervisor and kernel feature set thus granting support for newer hardware.
Otherwise, feel free to open an issue on the Qubes issue tracker and the Core Team will look into it.
Hope you don't mind the flamboyant title, but, I truly do believe that the small attack surface of the heavily minified Xen hypervisor, networking stack, GUI virtualization, and much more Qubes OS employs + the Whonix intergration implemented in this project (making it a Windows-Whonix-Workstation; thus also giving it Tor-only Internet access with stream isolation between other VMs) makes it the most secure and private way to use Windows currently available today. Those are just the two main points, besides that, there is also the fact that because everyone using this project is both having their Windows VMs set up in the same way and running Qubes OS, that greatly helps to keep the OS and hypervisor fingerprint homogeneous across all users. This effect will only grow stronger as the Qubes OS userbase increases. Lastly, if the user wishes to reset their fingerprint, they can automatically do so by reinstalling Windows with this project.
Of course, I would be happy to go into detail and answer questions about any of this.
Note that this project is the product of an independent effort which is not officially endorsed by Qubes OS or Whonix.