Is there anyway to get Windows tools working on 4.2?
There was a recent discussion on this
2 Likes
Tried that solution 2X now. Still can’t get copy/paste between VMs or devices to attach to the Windows qube.
Anyone else able to get windows tools to work in 4.2?
DId you try
sudo qubes-dom0-update qubes-windows-tools-4.1.69
and then to check if it works?
Tried that, as well as downgrading.
Doesn’t seem to be working.
Sorry, no other ideas.
Did you check “Send To” submenu of a context menu? No entries there? Or you couldn’t install it at all?
You should better describe the issue.
Xen project has released new drivers and updated their initial security announcement (related to QSB-091) with the action but still will need to wait for QWT to be rebuilt with them.
You can try installing drivers manually which should allow attaching devices but that probably won’t give you copy/paste.
ACTIONS TAKEN
=============
The possibly compromised system has been decommissioned.
We have removed all previous binaries from:
https://xenbits.xen.org/pvdrivers/win/
A new set of drivers based on the current master branch
(9.0-unstable) and built on a trusted environment have been uploaded
on the same folder with the following hashes:
$ sha256sum xen*.tar
b089[...]
1 Like
The Qvm-Create-Windows-Qube tool works on R4.2 using these v4.1.67 QWT tools.
Copy & paste works fine in the generated Windows HVM.
That’s using the likely compromised drivers though. I would watch this pull request from marmarek which is working toward using the clean drivers.
I’m working through this as I find time.
3 Likes
Is it really compromised?
It was a big enough risk that xen decommissioned their build system and deleted all old versions of the drivers from their website. The only version of the files currently available is 9.0.0.
Software used to build previous versions of the Windows PV drivers was affected by multiple vulnerabilities, all previous binaries have been removed
I would say yes, the system was made vulnerable quite severely to trigger that type of response.
I was able to get this working and have copy / paste functionality as well as file transfer capabilities by compiling a custom QWT with the following:
- Modify the location of the PV drivers to point to the correct web address (I actually used my own mirror)
- Compile QWT
- Install Windows and boot with QWT ISO mounted (
qvm-start --cdrom qwt-app-vm-name:/path/to/qwt.iso your-windows-vm) - Copy QWT executable to machine
- Turn on
testsigningandnointegritychecksand Restart - Run QWT installer and when prompted, click yes to allow install of unsigned drivers
The build steps followed the same flow outlined on the QWT repo except you’d want to build your own with correct file destinations and may need to adjust some code for signature verification. I did base off of this forked branch (thank you @marmarek).
I ran into several issues with this initially but I haven’t taken the time to reverse them to see why. To make my life easier, I ended up using the DISTFILES_MIRROR parameter in the Makefile make DISTFILES_MIRROR=https://www.example.com/dev (also important to note that you update the repo to your modified one).
Another option that should work is to allow unsigned drivers, reboot, and then install the drivers manually with their own installers. Finally, use an existing QWT installer for everything except the drivers (specifically right-clicking on the PV Drivers in the list of things to install, setting it to not installed).
P.S. The “move user profiles” QWT option which should allow for template usage bricked the install. If you leave that disabled, you should be fine.
1 Like
But doesn’t that will compromise the dom0 itself?
Only if there’s an exploit that allows escaping from an AppVM but that would be a much larger problem. This approach is the same as the previous ways. Nothing is executed in, or mounted by, dom0.
But these drivers responsible for the communication between dom0, isn’t?
They don’t list CVEs, so it’s very possible there’s a security risk for dom0.
They are Windows drivers for xen virtualized hardware installed inside your Windows VM. They do not provide any channels to dom0. The drivers have nothing to do with QubesOS.
For them to impact dom0, there would have to be a flaw with the xen hypervisor that allowed escalation to the remote host. This would be a much larger problem than Windows, or QubesOS for that matter, as it would be a critical flaw affecting all xen virtualized environments.
The Qubes Windows Tools package provide a Qubes RPC Agent that allows dom0 to execute commands inside Windows. This is separate from the xen drivers mentioned throughout this thread.
3 Likes
I tried to install these Xen drivers to a Windows 7 system. Unfortunately, this leads to an unbootable system. So the version 9.0.0 drivers seem to be incompatible with Windows 7, leaving a big problem for the last usable version of Windows.
1 Like
I will still take it if it runs on Win10/11. Seamless Windows is a great selling point and a feature of QubesOS.
As long as it is seamless, W10/11 is not quite as ugly as run natively. 
2 Likes
Which driver caused the issue? Keep in mind not all of those on the download page are required. QWT only installs 6 out of the 8 available and a couple of those are for performance, not functionality (I think, like xennet).
I would recommend installing one at a time, shutting down, and snapshotting between each. Install what you can, and report which one in particular causes the boot issue.
I doubt xen is going to remedy any Windows 7 driver issues since it was sunset over 4 years ago and has a ton of critical CVEs open but you should be able to get partial functionality with a smaller set of the drivers installed.