From my understanding it looks like new xen PV drivers for windows have been updated to resolve the previous potential vulnerabilities.
Hopefully this means that sometime in the future we might see new releases of qubes-windows tools.
8 Likes
Hoping for this as well.
Is it still not solved?
3 Likes
If not, it makes R4.2 the first Qubes OS version that does NOT support Windows VMs properly.
Such situation is worse than ever, even worse than Qubes OS R1/R2 where this feature was advertised as a major feature on screenshots.
3 Likes
Hi,
Is there any secure solution to the QSB-091 problem? Like now or in forseeable future?
Or at least some vague information on the current status and when we could expect it to be fixed?
Why it matters for me:
I hope nobody interprets this as agressive or mean, it is not meant that way, but this is a pressing issue for me.
I am one of the few brave souls that dare to use QubesOS as their work OS (pentesting), and i really love it and will likely never switch back.
However being a security professional that handles very sensitive data i cannot just accept the risk in behalf of my clients easily, while simultaneously being dependent on the availability of those features (clipboard at the very least). Some tools i use only run on windows and i need those tools.
So any information however rough they may be are really appreciated.
6 Likes
You could get a physically separate Windows computer to compartmentalize your Windows dependencies; they are a dime a dozen.
Perhaps you could also build the compromised Xen component from source and then QWT. But I donât know how complicated that will be.
But I agree it that itâs an unfortunate situation.
Also, super happy to see a cyber security professional using Qubes. Given that in this profession youâre already at heightened risk, I find it curious why most professionals so easily dismiss Qubes.
The issue with Windows not working properly on Qubes OS R4.2 should be indeed addressed sooner. It is one of major features of the Qubes OS, that is broken that much first time in its history.
Also we should take into account the fact that user cannot use VirtualBox or other software to run Windows in Qubes OS. Windows has to work on Xen, no alternative running solutions are available (right?)
2 Likes
Perhaps you could also build the compromised Xen component from source and then QWT. But I donât know how complicated that will be.
But I agree it that itâs an unfortunate situation.
Also, super happy to see a cyber security professional using Qubes. Given that in this profession youâre already at heightened risk, I find it curious why most professionals so easily dismiss Qubes.
1 Like
You could get a physically separate Windows
Thank for your proposed solution, but unfotunately this wont work for me.
While this is the approach i took for my personal system(s), in a corporate setting it does not work that way.
I have one company issued laptop and i am pretty certain that my IT department wont give me another one just because i use QubesOS and âthere is a security situationâ. They will say âuse another OS thenâ.
Dualboot might work technically, but this greatly slows down my work, costing more money to my clients for getting less.
Also, super happy to see a cyber security professional using Qubes. Given that in this profession youâre already at heightened risk, I find it curious why most professionals so easily dismiss Qubes.
Thanks! Fully agree with you. Many of my colleges are interested in qubes and i will pitch the system in an in house presentation.
We virtualize everything anyways, so QubesOS is the most obvious OS choice imo. I think this topic deserves its own thread because there are many things to consider and i think i have kind of a good understanding as to why i am the only one in my company doing this.
1 Like
You can consider using RDP from another qube as a quick workaround.
Thank you very much!
This is a great idea that would work basically flawlessly for me from an usability perspective and would offer enough security.
2 Likes
I hope I donât get flamed for ignorance but I have Windows 7 and 10 running on Qubes 4.2. (as stand-alone HVM) I have been running Qubes as my daily driver since 2018 so I have a pretty high tolerance for experimentation. I read that Windows with QWT, would not run in 4.2 but since I had been running Windows on Qubes since 3.x I figured I give it a try on 4.2
All I did was do a clean install of 4.2 and then restore my Windows Qubes (4.1) and they worked as before including copy / move to another VM. I donât use seamless mode so I canât comment on that. I really didnât expect to have the integrated clip-board functionality, but I do. Go figure!
If anyone @Gweck could enlighten me on why I seem to have full Windows functionality on 4.2 please do. Is it maybe because its a stand-alone HVM qube?
If you have installed QWT before, when the Windows qube was running on Qubes R4.1, then it wouldnât suddenly lose QWT capabilities upon restored, however it wouldnât be exempt from the potential vulnerabilities from Xen Windows PV drivers either.
I did pretty much the same thing estoner did, and I did so last night.
(Iâm glad I remembered to back up the template and appvm before I decided to upgrade my desktop machine! Thanks to this topic I was reminded of it. I donât use the windows qube often, but when I do I absolutely need it.)
Unfortunately it took until about 4AM to restore the backup on my laptop so I didnât get the chance to verify qvm-copy works (both incoming and outgoing) but it sounds like it should. One thing that I did try, that doesnât seem to work, is attaching a drive to the Windows VM. I will verify (or with better luck, see my mistake) this tonight (once I get back to where I left my laptop charger!).
I can confirm that, having backed up a 4.1 Windows VM (and its template) and then restored them on a 4.2 box, qvm-copy works (which is good, because that is a barely-tolerable workaround).
Unfortunately I cannot attach devices to the Windows qube and have them show up as Drive D: (or E:, etc.). (And I made sure the device was FAT formatted.) So itâs a good thing qvm-copy-to-vm works!
I was thinking of upgrading my 4.1 system to 4.2 next weekend. Now, I think I had better wait.
2 Likes
Wow, big deal for everybody who uses it.
Do you see it inside the qube not as a letter D:, E:, etc, but in Windows Disk Manager tool?
Have you reported this issue to github or was it already reported?
I did some testing which came out to a pretty complicated situation, which I described in issue #8328 and which, so far, is not solved.
The situation can be roughly described as follows:
-
If a Windows qube from R4.1.2 with QWT - no matter whether standalone or template - is backed up and then restored to R4.2, the Qubes menu entries for that qube are destroyed, but otherwise it works with QWT from 4.1.2.
-
The situation is a little bit better if QWT is uninstalled before backing up the qube under R4.1.2. (If you do that, be sure to clone the qube before uninstallation, as this may break it !!! ) Installing QWT .69 to the restored qube under R4.2 will lead to a working Windows and QWT, if neither the optional PV network and disk drivers nor the Qubes GUI agent for Windows 7 are installed.
So, if you can do without seamless mode for Windows 7, which is not available for W10 or W11 anyhow, you can work with Windows and QWT under R4.2. (For me, unfortunately, this is no real help, because I need Windows 7 in seamless mode. 
)
3 Likes
Broken menus may be restored manually, if the contents of /home/user/.local/share/qubes-appmenus/VMNAME/apps/ in dom0 are copied from the R4.1.2 installation to the R4.2 installaition, and the same is done within the Windows qubeâs registry with the contents of HKLM\SOFTWARE\Invisible Things Lab\Qubes Tools\AppMap.
Caution: Applying qvm-sync-appmenus or the Refresh applications function from the Qube Manager will break the menus again!
2 Likes