Windows support in Qubes

After a sleepless night, I came up with some considerations, and I hope I can start a discussion based on these ideas.

Currently, about three fourths of all desktop computer are using Windows as their operating system, despite serious security problems. Still about one sixth of them are still using Windows 7, although support for this version has been canceled last year. The majority of the Windows systems - about 80 % - are using Windows 10, which poses severe security risks: Each month, Microsoft has to issue a series of patches in oder to mitigate security holes, and all too often these patches create new problems, up to boot failures and inaccessible devices. On the other hand, the many security holes that surface permanently allow severe attacks like infections of Trojans like Emotet, which may ruin the complete installation.

Furthermore, the use of Windows 10 is illegal in the EU, if personal data are processed and the telemetry transmission is not blocked. The GDPR requires that any transmission of personal data to a location outside of the EU is inhibited without explicit consent of the concerned persons. With Windows 10 up to the Professional version, this cannot be guaranteed if the system is connected to the internet, because the telemetry cannot be completely switched off. Especially small installations, like for instance doctor’s offices, have no choice of buying the LTSC (enterprise) Windows version which allows to disable telemetry completely, and mostly they have not the money and the knowledge to protect their systems adequately.

But still these systems are used for a lot of sensitive data processing, mostly because they are dependent on application software which is available only for Windows 10. Replacing these systems with open source without telemetry is not possible, because their applications are simply not available for Linux. The user therefore just has to select between illegal data processing or no data processing at all. One sad consequence of this situation is that Linux, after all these years, can be neglected as a desktop system, as its market share is still below 2 %.

In this situation, a tool to use Windows in a secure way is desperately needed. Qubes provides such a secure environment for using Windows, if the Windows VMs are installed as pairs of Template VMs and AppVMs. The Template VMs can connect from time to time to the Microsoft servers in order to validate the software licenses for Windows and Office 365, but they do not contain any personal data, and no applications need to be started on them, thus reducing the risk of their compromise considerably. On the other hand, personal and other sensitive data can be kept in their corresponding AppVMs, which should not need any internet access, as applications like mail and web browsing can be performed from Linux AppVMs. Additionally, external documents can be sanitized in dispvms before being passed to a Windows VM for further processing. And if, anyhow, a Windows AppVM should get compromised, any malware that got stored in the system part can simply be removed by restarting the AppVM.

For these reasons, Windows support in Qubes is of high importance. Regarding the relative distribution of Windows and Linux desktop systems, a good Windows support within Qubes may help to promote the number of Qubes installations considerably. Currently, Qubes supports aabout a dozen Linux flavors, which in itself is a good thing, but still a niche market. Providing better support for the mass market, i.e. Windows, would make this fantastic system still much more useful - and the Windows users need all help they can get.

So, what should be done? In order not to overload the core development team of Qubes, who do an excellent job, especially rearding the very limited resources available to them, Windows support currently looks as something deserving community activities.

  • In the short term, it would be helpful, if, based on the very good preliminary version of Qubes Windows Tools (in December it was 4.1-65) an rpm file for installing and testing should be provided and made downloadable from a community repo. This would help all those users who are not able to build QWT themselves, and I suppose these are the majority. (Here I am looking at @elliotkillick, (@Eliot1984 ?) @jevank (@tabit-pro ?), @fepitre, and perhaps some others.)

  • In the mid term - say to the release of Qubes R4.1, a version of QWT should be provided where the current problems (limited graphics support, especially only some screen resolutions; missing start button for Windows 7; perhaps even seamless mode for Windows 10; still some glitches during installation; scratchy audio) are solved. Support for Windows 7 should not be dropped, as this system still can be used securely as a Qubes VM, and for several environments it is still vastly superior to the buggy, un-ergonomic Windows 10.

  • In the long run, Windows support should be as stable as the support for other systems. Perhaps a solution like for Whonix could be found, where the workload is mainly carried by developers outside the main Qubes team. If this might lead to a larger user basis for Qubes, maybe it might also help to acquire some fund for the development. (I am perhaps daydreaming…)

I hope these considerations may start a discussion which could lead to some tangible results, and I am looking forward to hearing from you.

11 Likes

I am in agreement with @GWeck. The lack of OK support for Windows based Qubes is what is preventing me of using it as my primary computer for work.

I am no dev, but I am willing to help testing there is good doc on how to build the build environment.

Please let me know where I can help!

Bishop

Hi to community, glad to hear that some of our project are relevant. I’m agree that Windows support for Qubes OS is helpful to get more users coming, but it takes time a lot (for testing/debugging in different environments mostly). So may be community repo project is a good idea.

Qwt-crossbuild project (part of qway-qubes-repo at now) could be useful to keep Windows integrated with coming 4.1 version. Core functions (based on qrexec) - copy-paste and file exchanging works pretty fine with Windows 7 and 10. We are not building binaries from out repository because it looks like users mostly will not being trusting them. But it is not so difficult to build it with our how-to pages (wiki part of repository) and we are trying to get it to upstream if possible.

Our actual activity for Windows integration with Qubes OS is out of qwt, but in core components to get emulated access to audio (already upstreamed) and USB subsystems (is on the way to upstream).

We are not part of Qubes dev team, but we have strong interest in it development.

Ivan Kardykov aka jevank
tabit.pro

4 Likes

Thanks @GWeck for the summary and picking up this topic!

There are two main reasons why there is no recent official QWT build:

  1. The build process is a manual, time consuming thing (qubes-builder-windows/README.md at master · QubesOS/qubes-builder-windows · GitHub)
  2. There are no automated tests at all, meaning all the testing is done manually (including the basic tests like “does it boot at all”). And I’m kind of reluctant of uploading totally untested things even into current-testing repository.

For the first point, there is an attempt at improving it by cross-building with MinGW on Linux (Make Qubes Windows Tools build with MinGW · Issue #5065 · QubesOS/qubes-issues · GitHub) - this makes the process much less painful. But as you can see in the comments, there are still some regressions compared to Windows build (or at least they were before - already almost 2 years ago…). There is also Qway-qubes-repo/qubes-windows-tools at master · tabit-pro/Qway-qubes-repo · GitHub (thanks @jevank for the work!), and if that works already, it would be much closer to what we need. But I have one important request: while I’m not insisting on building each component separately anymore(*), I do insist on proper source code integrity checks. Currently the spec file list URLs like https://github.com/QubesOS/qubes-core-vchan-xen/archive/mm_f40b71ac.zip#/qubes-core-vchan-xen-mm_f40b71ac.zip, and nothing verifies their integrity (we try to not rely on the integrity of github.com). I think the easiest thing to maintain here, is to use git submodules and create source tarballs in a makefile (like qubes-linux-kernel/Makefile.builder at master · QubesOS/qubes-linux-kernel · GitHub). It’s easier than storing a hash of each component explicitly and update it manually each time, plus you can trivially check signature on the commit/tag when updating it. Similar comment applies to other things downloaded during the build process (devcon?)- if no other method is available, at the very least store an expected hash in the repo and compare it after download.

As for the second point, I think GitHub - elliotkillick/qvm-create-windows-qube: Spin up new Windows qubes quickly, effortlessly and securely could be a great help here. Ideally, I’d like to have this all integrated into openQA workflow, but even if I get a script that takes specific qubes-windows-tools.exe (or .iso, if that’s the build product) and tells me whether the Windows VM with it installed started or crashed, that would be a major improvement already.

With the above solved, we can have normal builds of QWT, which will unblock much easier collaboration on specific issues and features there (there are already quite a few fixes in the repository that never got released in the official binary).

(*) The Windows based build system, builds each component (gui-agent-windows, core-agent-windows, etc) separately, and builds an installer “merge module” out of it. This allows cleaner separation of tasks, and kind of enforces proper interfaces between them, but apparently introduces a lot of issues when cross-building from Linux. Previous attempt at cross-building used Wix fragment files to workaround this problem, but it also wasn’t that convenient. I realize this is a classic “perfect is the enemy of good” problem, and I think I’m fine with building all of it together. Ideally, I’d like to preserve VisualStudio compatibility (apparently it is quite helpful for Windows developers), but I’m not going to block on this anymore.

9 Likes

Thanks @marmarek for keep trying to get things better!

For the 1 point I hope we can at least build version of QWT for further community testing.

@GWeck Thank you for all it testing and I here is some details and workarounds we known:

  • Installation without gui-agent (WIndows 10 case) sets gui qvm-feature empty which is not false, so you will see no window next boot. It needs to be unset or 0
  • QWT installation time-to-time (always?) activates memory balancing, it would crush VM
  • It is better to run installation as Administrator to complete our preparation script which disable recovery mode and recovery console. It helps next boot if you get BSOD
  • Disk pv drivers in my case are pretty stable (we builds with 8.2.2) and gives more performance, but it is better to install with second try after moving profile
  • Within installation say no reboot question because it might be driver question and installation didn’t finished yet.
  • Copy-Paste doesn’t works first boot after installation. Next times all works fine.
  • Audio is really scratchy, but there is no QWT in it, device emulates by QEMU. Upstream version use version 4.2, we updated it to 5.1 and it seems better. @marmarek I could PR this, but right after USB request I guess
  • It is better (Windows 10 especially) to set qrexec_timeout to 9999 to prevent possibility to break windows updates applying
  • We don’t use block device hotplug attaching and advise you too
  • We removed QubesNetworkSetup, but bring qnetwork_setup script for manual configuration.
  • We have version with 9.0.0 pvdrivers, it gives no advantage and have some problem with uninstalling. Perhaps with next release will be better

And we did not try it on 4.0.

UPDATED: Network pv drivers has DCHP issue, so we disable it by default

2 Likes

A nice breakdown of Seamless integration of Windows in Linux has been published recently by Wendell from Level1Techs.

The insights from there could prove useful for Windows support in Qubes. In particular the use of a windows RDP component to do the heavy-lifting of window decomposition in windows 10. Qubes is briefly mentioned in the video as well.

1 Like

I tried the Xen 9.0.0 drivers with Qubes R4.0.3. There, they are needed for Windows 10, as the 8.2.2 drivers did not provide a stable use of QWT. Loading the 9.0.0 drivers in Windows 7, however, crashed the VM. So it may be necessary to have two versions, 9.0.0 for Windows 10 and 8.2.2 for Windows 7. This is ugly, but, compared with Windows 7, W10 is still uglier :frowning:

Now there’s hope around the corner! :joy:

1 Like

We see no problems with 8.2.2 in Windows 10, qwt-4.1-65 build contains it. Can you describe more details?

It’s still some time, since a made these tests, but as far as I remeber, W10 started, but qrexec did not work, and then W10 was killed after timeout. Another problem were crashesafter each other boot. I’ll try if I find the description somewhre and post it.

The tests are described in Qubes issue #5462 Qrexec Agent Starts Incorrectly and too Early on Windows 10 HVM.

I`ve read intently and looks like all problems describe official builds, which should be obsoleted for Qubes 4.1.
I hope we are moving to get official build with necessary modifications.

1 Like

I think I made a Windows 10 template hvm that seems to work ok:

  1. Download the windows 10 iso (i picked the home edition) and install it to a HVM. The admin account’s name should be “user”.
  2. setup autologin with registry.
  3. format private drive to a E: drive with a ntfs partition with disk management before installing qubes windows tool to work around a problem. don’t need the newest xen driver or .net 3.5.
  4. move user profile with sysprep after qubes-windows-tool copy it to
  5. update windows 10
  6. robocopy the “C:\ProgramData” folder to “D:\ProgramData”
  7. move programdata with sysprep (have to do this after updating or you will get stuck in a reboot loop). If you don’t move the progamdata folder, the windows 10 app vm will be unbootable forever after you boot the
    windows 10 template hvm.
  8. I think I manually edit the registry to change all “C:\ProgramData” to “E:\ProgramData”. I don’t know if this is necessary. It takes 10-15 minutes. I can’t change the registry for windows defender, but that seems to be fine.

I also remove all apps (provisioned or not), cortana, old edge (the new chromium edge is not removable), 7GB system reserve on hard drive, and disable some telemetry with windows 10 debloater. I also disable indexing. Set size of virtual memory to 0 MB. Windows update seems to work.

When systemprep asks you to make a new account, make a new one and then delete it. When windows wants to restart, you have to manually restart. If qrexec timeout, set the timer to 5 min, as described here: Contents/windows-vm.md at master · Qubes-Community/Contents · GitHub

Copy and paste between Windows 10 qube and other qube works. Copy/move to or from other qube works. However, the seamless integration doesn’t work. After installing the qubes windows tool, i made a dom0 script:

#!/bin/bash
qvm-start $1 && sleep 1 && qvm-start-gui --force-stubdomain $1

To resize the private drive. resize it in qube setting and then go to the disk manager of windows 10 to extend the partition on the private drive.

1 Like

A post was merged into an existing topic: Starting windows 10 HVM gives an error block device dom0:loopX not available

I’ve managed to get some of the Qubes support working in a Win10 HVM.

Things I have working:

  • Assign a USB thumb drive (or any block device) to the Win10 HVM and Windows sees it!

Things not working:

  • Assign any other kind of USB thumb drive (e.g., webcam or smartcard reader) causes an error; Qubes gives a message about qrexec.

I wrote up my findings on Reddit: https://www.reddit.com/r/Qubes/comments/nasggo/libxenvchandll_missing/

As far as I can tell, the drivers seem to work. However, the install code does not. qubes-tools-4.0.1.3.exe fails to copy or install the DLL files under Windows 10. I manually copied xencontrol.dll and libxenvchan.dll to “C:\Program Files\Invisible Things Lab\Qubes Tools\bin” and then the Windows services for Qubes started up. That’s how I got thumb drives working.

The xencontrol.dll comes from Xen Tools 9.0.0 iface.

Getting libxenvchan.dll is a little more difficult:

  1. In qubes-tools-4.0.1.3.exe, use cabextract to find the internal files. File “a1” is an executable.
  2. Use 7z to extract the file named “content.cab”: 7z x a1 content.cab
  3. Then use cabextract again to find the DLL file: cabextract -F libxenvchan* content.cab

The biggest problem I’m having: The cab file contains lots of additional sys and dll files, but I can’t figure out the actual names, where they belong, or what registry settings are needed to make them work. I suspect: If I can figure this out (or someone is kind enough to tell me), then all of Win10 support will work.

In other forums, there are a few people who say that they have full Win10 support working under Qubes. In each case, they said that they compiled it from source. That’s why I think the main problem is the install script and not the drivers (sys, dll, etc.) themselves.

Hi, it’s Elliot. Just created my account on this new forum. Heard about this thread thanks to @deeplow posting it on this issue: Qubes Windows Tools (QWT) on R4 · Issue #3585 · QubesOS/qubes-issues · GitHub

I’m curious as to what exactly the established game plan is for further QWT development then. I’d be interested in integrating community work into qvm-create-windows-qube if this is to come in as a pure community effort. Additionally, I’ve never attempted to build QWT myself but I would be up to submit a few patches should we be able to figure out how to do so.

If we were to stick with the Windows build system for now then I could make changes to qvm-create-windows-qube to facilitate the easier creation of a development environment for working on QWT. For example, a new option on the qvm-create-windows-qube command such as --qwt-build-env. This option could, for example, grab all the necessary Qubes/Xen repos, enable driver test signing to test the yet to be signed drivers under development, install Visual Studio and windbg (with Chocolatey) and more. This would also help make contribution a lot easier, ideally just a single qvm-create-windows-qube command to get straight into developing QWT.

4 Likes

I wish I knew. This has been a known problem for years, but there’s no timeline for a resolution and no clear owner. Worse: I can’t seem to find instructions about where to get the source code, how to compile it, what dependencies are needed, or where files get installed.

I’m not a windows developer, but I’m willing to be an alpha tester.