Windows 4.2 Support Functionally Incomplete - User Impacts and Solutions

General Discussion
21

I am sorry if I am making noise. Can someone give a straight answer to my questions: if I backup fully working Standalone WinVM created under Qubes v4.1x, will it fully work under Qubes 4.2x when restored?

Also, if the answer to previous is Yes, what are security consideration differences between using such a Standalone WinVM under Qubes v4.1x and Qubes v4.2x?

2 Likes
22

I think the most recent QWT status is in the Github issue linked in the post above yours (alimirjamali’s response to me).

Don’t let the issue date (2016-ish) fool you… the discussion towards the end is current.

23

According to the issues on the QWT Github (linked in the post above), I would definitely say no. It’s likely not even to be bootable.

Once they get it working, though, I don’t think the security considerations will be all that different, though the security issues related to QSB-091 should be resolved.

You’re basically running a windows VM on a mostly well-sandboxed hypervisor OS. As long as you maintain the firewall setup and keep your Windows VM clean (and keep qubes updated), the security should be about the same.

That said, I am not certain any particular security enhancements that 4.2 brings will change the security profile of a Windows VM all that much, save for just from general enhancements to Xen and newer Linux kernel, like the one the stub domain is running on.

24

I have this exact question. It makes R4.2 kind of useless if one ever wants to migrate Windows qube and use it.

2 Likes
25

Well, I have the answer. It will not work, at least when in-place upgrade is. And, I suspect no way it will work, regardless of the way of upgrading to 4.2, when Xen PV disk drivers are installed in Win S-HVM. If I knew this, I’d backup the one working under 4.1, then uninstall Xen PV disk drivers, then back that version up, too, then upgrade to 4.2, then restored both (qwt<=4.1.69-1). The second one should work, while being able to attach external storage via qvm-usb. Which makes it unusable for non-primary internal storages.

1 Like
26

I did start Qubes-OS just recently. Level 4.2.2 i guess. So I did give Windows 11 a try and it basically works. Many cool features rely on those QWT. Though I think certain features rely on Home-Editions (autologin aint fun/possible going Windows Pro and beyond). Anyway I was interested in movetocube features, which dont work unless giving unsupported drivers a try.

Actually I dont need to attach a drive to that Windows VM. However I got curious as Qubes supports cubes to communicate with each other. I already set up a samba-fedora-cube for the sake of accessing smb-shares. Quite simple. Fun to create another template that fast.

As I am interested in testing Qubes capabilities I will try the following approach, which should work.

  1. Get another smb-cube running. This one will have usb drives attached to
  2. Add firewall rules - maybe set up another firewall cube sometime.
    3b. Windows firewall rules are bad by design. Need changes anyway.
  3. connect cubes by means of network
  4. enable Windows shares

Workflow in mind. Drives will be connected to that smb-cube which will become a proxy cube. Proxy cube could become a smb-target as well. Thus a network-drive from windows point of view.

So in order to avoid any unsupported drivers using a proxy-cube doesnt seem to be a big deal. I did install 11pro following documentation. No network issues.

Guess my approach addresses one issue only. Drivers do seem to do more. Like Qemu replacement for example. Also my approach wont resolve to attach drives to Windows by means of drivers.

1 Like