I have stopped using Windows years ago but I am facing the unfortunate need to use some specific software that doesn’t run properly in wine and requires actual Windows. (FWIW, it seems the software I have to use doesn’t need an Internet connection, so I hope I will never have to use any networking in the AppVMs.)
From the docs, I understand there are the options: Windows 7 or Windows 10/11.
I have an old Win 7 SP1 ISO and I don’t have a Win 10/11 license, so I decided to try the Win 7 route. There is something I don’t understand though:
QSB-091, section “Impact”, says “Dom0 is not affected” and says nothing about danger for Xen or Qubes itself.
“Due to the security problems described in QSB-091, […] a possible compromise of the Xen drivers used in Qubes Windows Tools might create a risk for Xen or dom0 and thus be dangerous for Qubes itself. This risk may be small or even non-existent, as stated in QSB-091. If you understand this risk and are willing to take it, you can still install the previous version of Qubes Windows Tools for Windows 7, which will work for Windows 7, but not for Windows 10 or 11.”
This sounds contradictory: “Dom0 is not affected” vs “risk for Xen or dom0 and thus be dangerous for Qubes itself” that “may be small or even non-existent”.
I surely don’t want to endanger Qubes itself but with such confusing information it is impossible to “understand this risk” and decide how to proceed.
You never stated what would you needed. That’s why I asked. Maybe you need them only in Windows. Maybe backing up Win 7 qube is enough, until you find some other solution.
Although I am confused how would you provide that specific software to Win 7 without QWT in the first place.
Although I am confused how would you provide that specific software to Win 7 without QWT in the first place.
Exactly. I can’t.
I tried attaching a loop device from a Linux qube to the Win7 qube but it didn’t show up there, so I assume even that is not possible. Hence the need for QWT and the current thread.
The situation is not as bad as it may seem at first glance.
As QSB-091 and the underlying Xen notice state, there is no known compromise of the affected Xen PV drivers. The security problem with Xen was that they can no longer guarantee that the driver code was not manipulated at build time. This may have happened, but there is no indication that it did.
Even if the driver code were manipulated, this would affect only the Windows VM using it, i.e., using version 4.1.69 of QWT. In this case, the Windows VM would become untrustworthy - which it is already.
As QSB-091 states, any compromise of the drivers in QWT would not affect dom0 directly, because they are never executed there. Probably they cannot be executed in a Linux environment, anyway.
Compromising Xen itself or, via Xen, dom0 would require an additional, independent hole in Xen. This is nothing new - if there is such a hole, you are sunk anyway.
As I read the documentation, the security problem described there does not mean that the drivers could still be manipulated. If they were clean when being built, they will stay clean.
Anyhow, there will not be much motivation to attack this software, since Windows 7 is rather ancient now. Unless there was a special reason for a targeted attack, current hacking activities will concentrate on current systems like Windows 11 since there are many more of them, and their software is, with hundreds of documented vulnerabilities each year, so lousy that attacks are much easier and much more promising. But running under Qubes, even they are protected, although staying untrustworthy.
To put it together, I would rate the risk of using Windows 7 in an offline qube as rather low. And, according to my experience, it is lightning fast compared with Windows 11 (if you have a rather slow lightning).
Thank you for taking the time to provide this exceptional feedback.
What you explain is exactly the logic I had in my mind but I was (and still am… somewhat) confused by the docs.
speed notes
And, according to my experience, it is lightning fast compared with Windows 11 (if you have a rather slow lightning).
Thanks for the additional info. I have always been skeptical about “latest and greatest”, especially when it comes to Windows. It took me a long time to switch from NT to XP in the old days.
BTW, speaking of QWT - has it any relation to Windows updates (in general, I know there aren’t any for the discontinued Win 7) in the context of a Windows template not having a NetVM (just like all templates)? Do you know how this works?
So, I installed the QWT (all features) in the template. The window did close itself and I had to kill the VM. After starting it the graphics driver and everything worked fine (seamless mode too).
I rebooted one more time, without doing anything else, and here is what I got (I hope attaching an image as a file via email will work, please let me know if it doesn’t).
As far as I can remember, you do not install all the features. The ones that are suggested as not to install, you do not install. That’s why this is happening to you.
well, outdated qwt is not a security risk per se. speaking on PV network drivers, they stopped working a couple of years ago anyway, so clipboard, qrexec and filecopy remain only truly functioning components in stock distribution :)) but old windows without security updates is not that good. does not matter in practice when non-networked, though.
The attack surface is pretty similar for any guest OS / PV drivers. Nothing windows-specific in it.