qubes-windows-tools: Support for Windows 10/11

[caschulz88]

Progress report from Qubes developer @omeg

Alright, since I (@omeg) have been working on this for a while now and finally it's in a state that will allow for user testing soon, here is the current status of Windows 10/11 support. More items might be added in case I forgot something.

All of the current code is here: https://github.com/omeg/qubes-installer-windows-tools/tree/omeg/win10
Don't use on production VMs, it's not ready yet. Make sure to set the default-user property for the qube manually as appropriate (#9020).

TODO:

• Core
  • Xen PV drivers
    • Core drivers (xenbus/xeniface)
    • Additional drivers (disk/network for performance)
  • Integration
    • Core services (qrexec agent, qubesdb)
    • qvm-run with passthrough i/o
    • AppIcon extraction
    • Clipboard integration
    • File receiving
    • File sending
    • Shell context menus for file sending and editing in other VMs
    • Initializing the private disk volume
    • Moving user profile to the private disk volume (QWT: redirect known folders instead of relocating user profile #5916)
• GUI agent
  • Secure attention sequence (CTRL-ALT-DEL) simulation
  • Fullscreen mode
    • Basic functionality
    • Resolution change on resize (limited by the basic display driver's hardcoded list of supported resolutions)
  • Seamless mode
    • Basic functionality
    • User account control (UAC) popups (desktop switch)
    • Capturing Start Menu and notifications
    • A way to interact with the tray notification area
• Installer
  • Component selection
  • PV drivers component(s)
  • Core component
  • GUI component
  • Proper versioning
  • Installing prerequisites (MSVC runtime)
• Building (no cross build on Linux possible anymore due to building Xen PV drivers from source)
  • Visual Studio build
  • Standalone build
  • Integration with Qubes builder

Nice to have (will most likely be done after an initial release):

• Release-signing for PV drivers (Release-signing for Windows Xen PV drivers #9019)
• Performance-enhancing OS tuning
• Windows 7/11 compatibility (11 seems to mostly work without issues)
• Seamless mode optimization (moving windows looks laggy)
• A GUI utility for various settings that are configurable via registry
• Custom WDDM GPU driver (for better performance and easier access to DWM-managed window surfaces)

Known issues (will be added to github once the code is merged):

• Stubdomain memory may need to be increased if you encounter Qemu being oom-killed (HVM stub-domain occasionally runs out of memory #3821)
• NTFS symlinks are not handled correctly by file sender
• Rarely some framebuffer changes seem not to be detected correctly in fullscreen mode

---

Original issue text from Qubes user @caschulz88

Hi,

I was wasn't able to find any already opened issue about this topic so I'm creating one right now. In all documentation on qubes-windows-tools there is always only the information that newer Windows versions than Windows 7 are in development.

Can anyone please clarify what exactly this means? Do we have a roadmap or special features, which are missing at the moment? Because the MSI installer has a hard check for Windows 7 version in it I wasn't able to run the installer on Windows 8 and Windows 10 in comatibility mode (as the user cannot specify a specific Windows version in compatibility mode as he could do when running some executable file). I bet there are some reasons to include such a check there.

Would be great to have this list posted here. I'm also willing to help to get support for Windows 8 and 10 of course!

[marmarek]

Indeed there is no open issue for that, but this is exactly what @omeg is doing right now. The most challenging is totally different graphics drivers framework (or more precise: removal of the old, simpler one).

[8tt]

Any updates on the current progress of the Windows 10 support? It would be very nice to be able to run Windows 10 VM in a resolution higher than default 1024x1024.

[marmarek]

Not sure about details, but drivers for running Windows 10 in
non-seamless mode are almost complete. Seamless mode will not happen
anytime soon (if ever...).

@omeg can provide more details.

Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[sveeke]

Since it has been 18 days since the last update: @omeg, do you have an indication when Win 8+ support will be ready? And just out of curiosity: what does in mean that seamless mode will probably never happen in Win 10? And does this also apply to Win 8(.1)?

[schnbrg]

@sveeke - seamless mode is when you can control an application window from a VM on the host destkop. It is sort of like "Unity" from VMware. I am guessing the graphics drivers framework that @marmarek mentioned are making it difficult to implement seamless mode.

Non-seamless mode is fine with me!

[brunoais]

Without any intention to add pressure to an awesome project I can get for free (Thank you!), and just with the intention so I can prepare myself to the vague date:
@omeg How complete do you think this ticket is and when does it seem this can be completed (even if you fail at it by a long shot)?

[andrewdavidwong]

@brunoais: No one is currently working on this (hence the help wanted label), so the answer to your second question is: If/when we receive patches from the community, or if/when the Qubes team has time to resume work on this, whichever (if either) comes first.

[brunoais]

@andrewdavidwong Oh! I didn't know those tags were because there's no one working on it. In that case, any ETA question makes no sense.
Thank you for that 2nd part of the answer, though. Even through it didn't make sense after knowing no one is actually working on it ATM.

[andrewdavidwong]

I didn't know those tags were because there's no one working on it.

In this case, yes.

Thank you for that 2nd part of the answer, though. Even through it didn't make sense after knowing no one is actually working on it ATM.

I'm not sure what you mean.

[brunoais]

I'm not sure what you mean.

As there is no one working on this, it doesn't make sense to have an ETA in a project such as this. Thought that, you still tried to get me an answer. I appreciate it.
Do you understand now?

[andrewdavidwong]

As there is no one working on this, it doesn't make sense to have an ETA in a project such as this. Thought that, you still tried to get me an answer. I appreciate it.
Do you understand now?

Yes. :)

[cmavr8]

(As noted before, I've no intention to add pressure and thanks for the great work!)
The following may help prioritization, now that development funding is available.

I argue that supporting newer windows is important for two reasons that have not been mentioned before:

• There is currently no way to run any version of properly-supported MS Windows for free. For occasional users of Windows, who may not want to pay for a full license for each VM, the only legal and free option is the MS Edge evaluation VMs that MS provides for free. Unfortunately, they only provide x86 Windows 7, which is not compatible with Qubes's guest tools. It would be great if we could get the tools working on Win10 since Microsoft provides an x64 version for free.
• Windows 7 will go out of extended support in about 2.5 years (January 14, 2020). It would be best if we have time to test guest tools on Win8+ before having to rely on them as the only option.

[tonsimple]

If at any point a tester who tends to work >4 hours per day in a windows VM and is willing to "get dangerous" is needed for this, hit me up :)

[anodium]

Let's get dangerous @tonsimple :-)

[Yethal]

@tonsimple how can I help?

[tonsimple]

@Yethal haha, I meant that I'm ready to test win10 tools as soon as they are ready ))

I use windows in qubes a huge lot (as evidenced with really obscure windows-on-qubes bugs I've managed to run into and submit) so I decided it may be neat to notify the developers that I am ready to be the guinea pig for the Win10 tools when the time is right

[Yethal]

Oh well, that's a shame. Anyway, if anybody needs a second pair of hands to help I'm here. I have a spare physical machine I can reinstall Qubes on over and over if needed.

[entr0py]

[Off-topic] For those desperate to use Windows 10 on Qubes, there is a (less secure?) alternative to qubes-windows-tools. As you know, Windows 10 installs and runs fine as an HVM on Qubes. Inter-VM interaction can be achieved using freerdp, which implements shared clipboard, shared folders, and seamless windows (via remote-apps). If your Windows VM is running on a separate HyperV host, you can have a fully functional, gpu-accelerated Windows 10 VM on your Qubes machine (via RemoteFX).

[krzivn]

@3n7r0p1 Do you have any pointers to pages on that? Most of what I turn up that deals with windows in Qubes is an after thought, old, or both.

Don't get me wrong, Qubes still absolutely rules and I hope someday it'll show windows how to actually do windows right.

[entr0py]

@krzivn Sorry to keep you in suspense. Discussion here: https://groups.google.com/forum/#!topic/qubes-users/dB_OU87dJWA

[bi0shacker001]

For resizing support, the qemu drivers support this for qemu guests
While I recognize that the integration work itself may not be portable, the way qemu handles changing resolution is by adding a resolution option to the list that changes dynamically. Maybe that's useful to implement?

[DemiMarie]

• Building (no cross build on Linux possible anymore)

  • Visual Studio build
  • Standalone build
  • Integration with Qubes builder

Is this because the new Xen PV drivers cannot be cross-built?

[omeg]

Is this because the new Xen PV drivers cannot be cross-built?

Yes. Previously they were not built either because we used binaries provided by upstream (and they no longer provide that). It's probably possible to make them build with Linux toolset, but that seemed like a significant effort when I tried.

[omeg]

For resizing support, the qemu drivers support this for qemu guests
While I recognize that the integration work itself may not be portable, the way qemu handles changing resolution is by adding a resolution option to the list that changes dynamically. Maybe that's useful to implement?

Yes, that's the "custom WDDM video driver" option. It was infeasible a few years ago when I first looked into this, but now there are some available examples like the virtio drivers that can be adapted. I'll look into that after the basic functionality works well enough.

[DemiMarie]

• Capturing Start Menu and notifications (partial - works, but those windows have weirdly huge transparent areas that need to be detected and discarded)

Do you expect this to be a performance problem in practice? This is a great candidate for SIMD acceleration.

[DemiMarie]

Is this because the new Xen PV drivers cannot be cross-built?

Yes. Previously they were not built either because we used binaries provided by upstream (and they no longer provide that). It's probably possible to make them build with Linux toolset, but that seemed like a significant effort when I tried.

What about clang in MSVC emulation mode? Clang’s SEH implementation is only partial, and that’s a severe problem for kernel-mode drivers. So I think using MSVC is absolutely the right thing to do here.

I am curious if one could (both legally and technically) run MSVC on Wine.

[bi0shacker001]

• Capturing Start Menu and notifications (partial - works, but those windows have weirdly huge transparent areas that need to be detected and discarded)

Do you expect this to be a performance problem in practice? This is a great candidate for SIMD acceleration.

At least the start menu should be negligible, since it occupies a fixed space on the screen. The values for that can be hardcoded (boundaries of the visible window), no detection required.

[DemiMarie]

• Capturing Start Menu and notifications (partial - works, but those windows have weirdly huge transparent areas that need to be detected and discarded)

Do you expect this to be a performance problem in practice? This is a great candidate for SIMD acceleration.

At least the start menu should be negligible, since it occupies a fixed space on the screen. The values for that can be hardcoded (boundaries of the visible window), no detection required.

I was not aware of that, which probably shows how long it has been since I used Windows.

[GWeck]

At least the start menu should be negligible, since it occupies a fixed space on the screen.

In Windows 10, position and size of the start menu may be chaned, and in Windows 11, at least the position may be changed.

For both systems, there are alternative start menus, like ClassicShell, available, which may behave differently.

[GWeck]

If possible, compatibility with Windows 7 should be checked/achieved, for at least two reasons:

• In some environments, usage of Windows 10 / 11 may be illegal; e.g. when working with personal data in Europe, the telemetry used in these systems will collide with the legal requirements of the GDPR. So usage of these systems is forbidden in several application areas in some countries/regions, e.g. in schools in some areas of Germany.

• Windows 10 and 11 are significantly slower than Windows 7 under Qubes,

Usage of Windows 7 under Qubes poses no additional security risk, as the system can be shielded against attacks from the net. So the lack of further support from Microsoft may not have significant effects on this system, and its use is still a good option if one is forced to use Windows.

[GWeck]

From qubes isuue #9102: Windows qubes imported from R4.1.2 to R4.2.1 should retain their complete functionality or, alternatively, EOL of R4.2.1 should be postponed until such functionality is available under Qubes R4.2.1.

Hopefully, if the work described here proceeds successfully, QWT will be available before Qubes R4.1 EOL. 😄

[DemiMarie]

If possible, compatibility with Windows 7 should be checked/achieved, for at least two reasons:

• In some environments, usage of Windows 10 / 11 may be illegal; e.g. when working with personal data in Europe, the telemetry used in these systems will collide with the legal requirements of the GDPR. So usage of these systems is forbidden in several application areas in some countries/regions, e.g. in schools in some areas of Germany.

In these cases I would expect the use of Windows 10/11 Enterprise or Education, which allows telemetry to be completely turned off. Otherwise, there are no officially supported solutions other than blocking Microsoft telemetry servers at the DNS or proxy level.

• Windows 10 and 11 are significantly slower than Windows 7 under Qubes,

Usage of Windows 7 under Qubes poses no additional security risk, as the system can be shielded against attacks from the net. So the lack of further support from Microsoft may not have significant effects on this system, and its use is still a good option if one is forced to use Windows.

The only time I can think of where Windows 7 is safe is when the system is permanently offline and never receives untrusted input. A permanently offline system will never be able to transmit telemetry data, though.

[bi0shacker001]

Windows 7 compatibility would still be useful, especially as it comes to playing older windows games in net-isolated VMs. But I'd also be an advocate for seamless mode and file transfer in XP for the same reason, so I'm not certain I'm the ideal audience to chip in on backwards compatibility (as most of my games are Visual Novels, and I'd REALLY like them to run well and seamlessly on qubes)

[GWeck]

Even if Windows telemetry itself is turned off, e.g. when using an education or an LTSC license, the use of this system is forbidden in the context of Microsoft 365 containing Office and other components like the Smart Screen checker. Turning access to Microsft servers off, as is sometimes suggested, does not work either: The telemetry functions access dozens of IP addresses that are permanently changing. So the only possibility to use the system in a legal way would be to block Internet access completely and allow access only to selected addresses via a whitelist, as can be done in Qubes. This, however, is no practical solution, because in smaller institutions there is no personnel available/able to maintain these lists.

For Windows, there are scenarios where the system is isolated from the Internet but allows local networks. This is allowed and, even for Windows 7, moderately secure. Working with the different Windows versions, I would not regard Windows 10 Internet access as any more secure than that of Windows 7 - both are crap, no matter what Microsoft tells. If you are using Windows 10, currently your system may be open to the Russian Midnight Blizzard hackers who stole important access tokens months ago - and Microsoft is not able to get them out.

So, in my opinion, it is extremely important to have good Windows support in Qubes. I see no other way to use Windows securely. Even if, as QSB-091 states, QWT is of doubtful security, this is still much better than using Windows natively, on bare metal.

[tonsimple]

I have windows 7 with multi-monitor config and in older Qubes I used the "debug mode + qubes gui driver", with seamless GUI disables" to get two separate windows that act (mostly successfully) as two monitors and can be placed around my multi-monitor setup as I see fit

I would be very grateful if @omeg were to implement something to allow this kind of usecase.
Stretching a single "virtual monitor" window (I don't use seamless mode much, prefer to keep all things windows as separate desktops) over multiple physical monitors is extremely punishing

Us multi-monitor users deserve happiness too 😸

[bi0shacker001]

Hey, is there any intention to start packaging these again? It looks like work is pretty much complete.

[omeg]

Hey, is there any intention to start packaging these again? It looks like work is pretty much complete.

Yes, it should be available for user testing soon.

[tonsimple]

Looking forward to that.
And if anyone has any hints as to how to get a "modernish" windows going in multi-monitor mode (as in, spawn 2+ different windows each of which is essentially a "monitor" in context of windows multi-monitor behavior, a-la what I could have gotten with Windows 7 running QGA+Debug-mode) I would greatly appreciate it and gladly test it.

[92VV3M42d3v8]

Hey, is there any intention to start packaging these again? It looks like work is pretty much complete.

Yes, it should be available for user testing soon.

Sorry for bugging, but when you are expecting release?

[jamke]

The information about progress of this issue is required. A lot of users are waiting for any information.

R4.2 should have not been released until this major problem is solved, because Windows virtualization with QWT has been a base feature of Qubes OS for something like 10 years or so.

[omeg]

Progress update: I'm currently finishing Qubes Builder integration which is required for official builds. I expect this to be done in around a week and probably a week more for review/testing. Current QWT branch can be built manually and is usable, the instructions are in the main repo in the OP.

[apparatius]

@omeg I've built the latest QWT for a test and I had a lot of graphical artifacts with it:

win10-qwt-new.mp4

It was the same for both full desktop and seamless modes.

Also I couldn't install QWT with qube's net qube set to none:

Maybe add a Skip button here to skip the check with a warning?

[Atrate]

@omeg For a user, would you recommend waiting for a stable release of QWT, building it from source or using the older, pre-dummy-package version? I'm planning to set up a Win10 template for myself and I don't know which path I should take.

[omeg]

@omeg For a user, would you recommend waiting for a stable release of QWT, building it from source or using the older, pre-dummy-package version? I'm planning to set up a Win10 template for myself and I don't know which path I should take.

I would recommend waiting for a stable release. While I've been using the new branch and builder-v2 integration is almost done, I've recently ran into instability issues with the Xen PV drivers. I'm still debugging them (random freezes, on driver sources that were working fine before).