QWT (support for Windows in Qubes OS) is not available anymore. When will this be solved?

Qubes Windows Tools (QWT) were removed from Qubes OS (replaced with a dummy placeholder file) due to potential risk of QWT being compromised.

I want to make clear, if possible:

  • What is plan for this situation?
  • How long will it take to make QWT available again? Dates, releases?
  • How users are expected to use QWT right now?
  • Should users consider upcoming R4.2 to be the first Qubes OS version in a while that does not support Windows running with QWT at all?

It is a huge step backward and definitely not what users want from new versions of Qubes OS according to feedback.

Users need some solution, not even permanent solution with reorganizing signing system, but any appropriate solution. Somebody has to raise this problem’s priority because Windows inside Qubes OS with QWT is crucial for many. It was one of the main things advertised in Qubes OS starting from R2 Beta with screenshots of MS Office running inside Qubes OS.


There is still 4.1.69 version of qwt in QubesOS repo: https://yum.qubes-os.org/r4.2/current/dom0/fc37/rpm/qubes-windows-tools-4.1.69-1.fc37.src.rpm

So if you wish to take the risk you can as well install it.

I think the reason for Qubes team’s decision to temporarily replace QWT with a placeholder README.txt is to save new users who do not read QSB from potential vulnerabilities, not to simply drop windows integration with QubesOS.

Basically this is somewhat an “upstream bug” that Xen team is more capable of resolving.

Also, from reading Security-critical code | Qubes OS , windows PV drivers are NOT part of security-critical code. So having them in your windows qube doesn’t instantly make the whole system vulnerable.

1 Like

Thank you for useful information about RPM. Do you know is this the last WORKING version of QWT for latest stable R4.1 release: https://yum.qubes-os.org/r4.1/current/dom0/fc32/rpm/qubes-windows-tools-4.1.70-1.fc32.src.rpm ?

It would be a bad thing to make further releases with dropping basic and long-existing functions.
The same disappointment happened to me with R4.1 and keyboard layouts. Something should be done to address painful regressions.

It makes people to be afraid of installing the next release, because something will be broken and not fixed for a long time. That explains why testing of R4.2 is not going well. E.g. I would love to install R4.2rc1 on a laptop for testing, but I am still not able to fix my main issues on R4.1, I do not want to make it worse.

Maybe the development process should be leaned a bit from adding new things towards making stable pivot releases that can be advertised/recommended to other people to work in a stable way for at least 1-2 years. At least add less new things that potentially can break stuff for users.
@adw , do you have any discussions about that on the Team?
I feel like development of Qubes OS is getting harder because there are too many things on the plate and priorities and plans are not obvious. At least for third-party viewers. I do not really see the list of plans and priorities for future releases as it was during R2 and R3 releases. Maybe I am wrong on that estimation.

I think the latest working QWT is qubes-windows-tools-4.1.68-1.src.rpm. 4.1.70 doesn’t have those PV drivers.

In fact existing Windows installs will not be affected unless you reinstall their qwt. And in fact testing R4.2 has nothing to do with neutralized qwt, as both packages for R4.2 and R4.1 are updated.

Anyway R4.2rc1 is still a testing release that shouldn’t be relied upon for production usage.

Maybe that’s because you are looking at the development too closely, and Qubes team members are too busy dealing with all sort of things :slight_smile: Large plans like switching to Wayland are obvious.

1 Like

Thank you. Will save these packages.
I understand that existing Windows qubes (potentially compromised) continue to work.

Well, I was talking more about keyboard layout propagation.
One user on forum recently said something like:

R4.1 was released 1.5 years ago and layout switching is not working, is it a joke?"

That was a moment I realized that for users that are not that much into Qubes OS and tech in general the current approach of new releases is a disaster.

I mean I can tolerate something painful like that but average user can not and should not. Imagine Windows 8 would not be able to layout-switch properly till the Windows 10 comes out. Would be a disaster, that is how people look at that.

And yet it is RC after all, so, if no NEW bugs found for it, it can be almost binary equal to release. But what about existing problems? I think those should be addressed before release.

1 Like

With regard to the older QWT versions: I tested .68 both on R4.1.2 and R4.2.0-rc1 - both worked. The other version .69 seems, according to its file name, to be compiled specifically for R4.2; I tested this there, and it worked, too.

In my opinion, if there should be no short-term solution to the problems addressed by QSB-91, the older versions should still be kept available, but installation may be accompanied by an appropriate warning. Installing and running Windows under Qubes poses, depending on one’s threat model, some risks, but in general, these risks will be much lower than when running Windows natively on naked hardware.

Still, the best solution would be fixing the problems upstream, but this may take some time, as it depends on the Xen development. Until then, completely blocking the installation and use of QWT may worsen the situation for users needing to run a Windows environment.


All this is useful, maybe deserves a short guide in the new section like “How to install Windows with QWT when it is broken at the moment”. Of course the reasoning why it is broken should be explained there.

I agree completely. Qubes OS does not have luxury of GNU/Linux with VirtualBox or other virt-software to run Windows in any alternative way. So, support of running Windows at least in some half-decent way should be kept.


I have brought your concerns to the team’s attention.

Well, Windows can still be installed in an HVM like any other OS, but it will lack the features of QWT.

1 Like

Thank you, that is appreciated!
If you have any plans/timing/news updates, please post it here.

Yes, that I understand. QWT is still a big deal to me, huge part of comfort of using Windows in Qubes OS without dualboot.


@marmarek says he will try to find the time to make QWT available with the final 4.2 release, but no guarantees!

Sounds like the Qubes devs will have to set up their own infrastructure to build properly-signed Windows PV driver binaries themselves in order to reach this goal.


I think the recent QSB about potential vulnerabilities in PV drivers needs to be looked at different angle:

  • First, it did not mean PV drivers have stopped working. Some of the drivers are buggy, but they more or less worked, and will continue working in the version of Qubes they are intended for.

  • In regard to vulnerability, it is just a huge non-sense. If you are adventurous enough to run the malware called M$ Windows in a VM, why does it suddenly matter if one more vulnerability is discovered in that same VM?

  • The reason QWT was replaced by a dummy was totally different: Because the official QWT package was designed to work with Qubes 3.x in the first place. It still worked with Qubes 4.0, but since the change in protocol of how VMs communicate with dom0, that QWT package became obsolete. There is updated version of QWT on GitHub that works with current version of Qubes 4.1 but AFAIK it is still not official.

  • Quote QSB-091: “We decided to use the Xen Project’s official Windows PV Driver binaries in Qubes Windows Tools (QWT) (rather than building our own binaries from source) because the Xen Project’s official binaries are signed by a special key that Windows accepts by default, which avoids the need to enable test-signing mode in Windows when installing the drivers.” It is just an outright lie to me. QWT contains the Qubes Video Driver signed by QUBES-AUTOGENERATED-CERT. Of course, it is not a “special key that Windows accepts by default”, so running Windows in test-signing mode is a must anyway.

  • If Qubes’ principle was/is “Trust Nobody”, now they got caught. They were lazy to compile the drivers from code, they trusted Xen guys blindly. And instead of a sincere apology and taking immediate action, they just annouced blabla. My trust in Qubes Team went down sharply since.

It never was “Trust nobody”, obviously. Otherwise provide a link to such statement.

Qubes OS has to trust: Fedora maintainers, XFCE developers, kernel developers and maintainers and another 1000 developers and maintainers of millions and millions of lines of code that was never possible to review by the small team of Qubes OS.

P.S. And please consider to be a little bit less aggressive on forum.


Disclaimers and notes

We would like to remind you that Qubes OS has been designed under the assumption that all relevant infrastructure is permanently compromised. This means that we assume NO trust in any of the servers or services which host or provide any Qubes-related data, in particular, software updates, source code repositories, and Qubes ISO downloads.

You may notice that the above is not my disclaimer. To my limited English, the quoted disclaimer means: Trust Nobody.

Thank you for your PS, point taken. But I will remain how I was born to this world. Hope you remain you too. You do not have to be me if you do not like it.

1 Like

Well, got what you mean. I though you were taking about general Trust nobody, but this quote is about infrastructure, servers and mirrors.
It is about checking signatures and hashes of dnf packages and other stuff. E.g. if somebody controls the physical servers of dnf mirrors - the installation will be rejected by Qubes OS due to signature check failures. Something like that.
From this point of view there is no much of a difference between trusting maintainers of Xen and of Fedora packages. In both cases the code is not compiled by the Qubes OS team. In both cases they trusted third-party with it.

1 Like

This is not true. I have posted links to the official Qubes repository where it provides qwt packages that work with R4.1 and R4.2.

Do you mean QWT got replaced because it’s not working with R4.1? What do you think now?

So, your reasoning is, Qubes video driver isn’t signed with the special key, so Xen Windows PV drivers also aren’t. I can’t see how Qubes video driver becomes a part of Xen Windows PV drivers.

Is this based on your experiment? From what I read in your post, it’s not likely you actually installed and used QWT in a windows qube.

So what? Qubes OS also ships firmware blobs that without them your PC probably won’t function properly, would you blame them for maintaining hardware compatibility?

No, it isn’t. There’s code that QubesOS trust: Security-critical code | Qubes OS . IIRC, the principle is “trust no infrastructure”. If this is what makes you do not trust Qubes OS, simply stop using it.

What do you expect them to apologize for? For not maintaining Xen’s infrastructure?

They immediately updated QWT without windows PV drivers. Would you expect them to take control over your PC and rip QWT out of it?


I asked the Qubes devs about this. Here is the information I received:

The situation with the PV drivers isn’t much different than it is with other VM packages. Templates use binaries built by upstream projects such as Debian, Fedora, and Arch. We do not rebuild everything from scratch. We ship QWT as an ISO that bundles both the PV drivers and Qubes-specific parts because Windows does not have proper package repositories. If it did, then the PV drivers would be a separate package (built by Xen), and QWT would depend on it. The main difference between the QSB-091 incident and other VM-related incidents (namely, the previous system update problems with Debian and Fedora) is that the Xen PV drivers team did not offer a timely solution. They took down the questionable binaries, but they did not provide new production builds.

Enabling test signing mode was required in Windows 7 if and only if you chose to install the qvideo driver. In Windows 10, testing signing mode is not required, since QWT runs fine without it, and qvideo is not supported.


I think that “trust nobody” is an oversimplification of what is stated. Let’s break it down:

We would like to remind you that Qubes OS has been designed under the assumption that all relevant infrastructure is permanently compromised.

This is saying that Qubes OS is designed to operate under a certain assumption. What is that assumption? It is the assumption that “all relevant infrastructure is permanently compromised.” In order to understand this statement, we have to answer a few questions:

  • What does “infrastructure” mean?
  • Which infrastructure counts as relevant here?
  • What does “compromised” mean?

Let’s look to the next statement for answers:

This means that we assume NO trust in any of the servers or services which host or provide any Qubes-related data, in particular, software updates, source code repositories, and Qubes ISO downloads.

The fact that this sentence starts with “This means that we assume…” shows that it’s here to clarify the previous statement. In particular, it clarifies and explains the assumption, mentioned in the previous sentence, under which Qubes OS is designed to operate.

“NO trust in any of the servers or services which host or provide any Qubes-related data” helps to answer the first question (“What does ‘infrastructure’ mean?”). We see here that “infrastructure” refers to things like servers or services which host or provide data. These are the types of things we’re referring to when we say “infrastructure.”

The phrases “Qubes-related data” and “in particular, software updates, source code repositories, and Qubes ISO downloads” help to answer the second question (“Which infrastructure counts as relevant here?”). We see that the relevant infrastructure is infrastructure used to host or provide Qubes and domU OS software updates (i.e., package repositories), Qubes source code repositories (e.g., GitHub), and Qubes ISO downloads (i.e., download mirrors). These are examples of infrastructure that count as relevant in the phrase “relevant infrastructure.”

Given this context, the answer to the third question ("What does ‘compromised’ mean?) is now pretty clear. It’s referring to scenarios in which someone uses the infrastructure to do something bad. For example, someone could hack into GitHub’s servers and try to mess with our source code, or a rogue employee at GitHub could do the same. We protect against this by cryptographically signing all of our code. This way, even if a hacker or rogue employee messes with our code on GitHub, we’ll always be able to tell, and we’ll know not to trust it. In other words, we don’t treat GitHub as an authoritative source for our code or as the source of truth for anything.

Similarly, any of our download mirrors could be compromised. When you try to download a Qubes ISO, it could instead serve you a fake Qubes ISO with malware inside. We protect against this the same way, namely by cryptographically signing Qubes ISOs. By verifying the signature on your Qubes ISO after you download it, you can determine whether it’s genuine or a forgery, so you’ll know whether to trust it.

What about software updates from package repositories? Same thing. Cryptographically signed. You’re probably beginning to see a pattern here. :slight_smile:

We call this general philosophy or approach “distrusting the infrastructure.” Here is our FAQ entry on it:

What does it mean to “distrust the infrastructure”?

A core tenet of the Qubes philosophy is “distrust the infrastructure,” where “the infrastructure” refers to things like hosting providers, CDNs, DNS services, package repositories, email servers, PGP keyservers, etc. As a project, we focus on securing endpoints instead of attempting to secure “the middle” (i.e., the infrastructure), since one of our primary goals is to free users from being forced to entrust their security to unknown third parties. Instead, our aim is for users to be required to trust as few entities as possible (ideally, only themselves and any known persons whom they voluntarily decide to trust).

Users can never fully control all the infrastructure they rely upon, and they can never fully trust all the entities who do control it. Therefore, we believe the best solution is not to attempt to make the infrastructure trustworthy, but instead to concentrate on solutions that obviate the need to do so. We believe that many attempts to make the infrastructure appear trustworthy actually provide only the illusion of security and are ultimately a disservice to real users. Since we don’t want to encourage or endorse this, we make our distrust of the infrastructure explicit.

Now that we understand what the disclaimer means, let’s take note of what it does not say. It does not say that we place no trust in upstream projects that we rely on, e.g., Xen, Fedora, or Debian. It also does not say anything about the infrastructure that those upstream projects use, own, or rely on. It says that we place no trust in “servers or services which host or provide any Qubes-related data.” It does not say anything about servers or services that host or provide Xen-related data, for example.

In other words, we do not try to police other projects or force them to abide by our standards. Even if we wanted to, we could not do that. We can’t force anyone else to do anything. All we can do is decide who we will trust, because we can’t do everything ourselves. For example, we can’t create and maintain the Linux kernel by ourselves. We can’t create or maintain Xen by ourselves. Those are whole projects in themselves, and they’re vastly larger than the Qubes OS Project. This is why “trust nobody” is unrealistic.

If we tried to do everything by ourselves, it would be evidence that we don’t really understand the nature of our own undertaking. As an analogy, it would be as if a small local militia in some town were to say, “We don’t trust the national military, so we’re going to defend the country all by ourselves.” Everyone can immediately see that it’s absurd and delusional for a small group of people with hand weapons to hope to defend against tanks, artillery, aircraft, warships, and ICBMs. Similarly, it would be absurd and delusional for us (the Qubes OS Project) to say, “We don’t trust the Linux Foundation, the Xen Project, the Fedora Project, the Debian Project, or anyone else, so we’re going to defend against cyberattacks all by ourselves.”

Now, you might say, “Well, I wouldn’t expect you to write all the code yourself to replace those huge projects, but couldn’t you at least check all the upstream code you use?” No, this is still a herculean undertaking that would be completely unrealistic for a project of our size. After all, there are multiple entire operating systems inside of Qubes OS, plus a hypervisor. Those gigantic upstream projects can barely even check all of their own code. Moreover, since most projects are not security-oriented, they probably never check their code in the way security researchers would (which is probably part of the reason projects and companies have bug bounties and why independent security researchers often discover major vulnerabilities).

“Okay, fine,” you might say, “but you should at least just check the upstream code that’s included in the Qubes TCB, right?!” At first glance, this might seem like an eminently reasonable request. Of course, we should check all the code in the Qubes TCB, shouldn’t we? After all, isn’t the whole point of Qubes to trust as little as possible? In theory, yes, but “trust as little as possible” isn’t the same as “trust nobody,” and in the real world, “as little as possible” is still quite a lot. Since I am not an expert, I asked @Demi about this. Here is what she said:

No. We do not even review all of the attack surface, such as Xen, Linux blkback, and Python’s regular expression library. There is even attack surface we have no visibility into, such as CPU microcode and USB controller firmware.

Reviewing the entire software TCB is only practical in certain embedded systems, and even there only because these systems are vastly simpler. If the entire TCB is 50,000 lines of code on a microcontroller, then one really can read the entire codebase in a reasonable amount of time, at least if one has access to all of the source code. In Qubes OS, the attack surface alone is quite a bit larger than that, and the TCB is many orders of magnitude larger – it includes Xen, Linux, and every other piece of code that runs in dom0, as well as the toolchains used to build that code. This is at least tens of millions of lines of code, and that is before one gets into the firmware, microcode, and other stuff that Qubes OS doesn’t even have visibility into, much less control over. Admittedly, not all of that code actually runs, but figuring out what does and does not is itself a nontrivial task.

In short, auditing the entire TCB is completely impractical, and auditing the entire attack surface would require far more resources than the Qubes OS Project has. If one wants to build a system people can actually use, one has to trust a lot of stuff.


For just getting back to the original topic:

  • I can’t find qubes-windows-tools-4.2.68 or 69 anywhere for download.

  • What is the way to install it in dom0? - With the cached repo on sys-firewall I’ve got no idea where to put this package for installation.
    A simple “dnf install qubes-windows-tools-4.1.69-1.fc37.noarch.rpm” is refused.
    “qvm-update install …” will not take anything not in the repo on sys-firewall.

1 Like

Are you using qubes 4.2. I think I read somewhere that 4.1.69 was only available for 4.2.

Also the command I used to successfully install it just now was

sudo qubes-dom0-update qubes-windows-tools-4.1.69


Outch, so simple … - I didn’t saw it …

I asked for a version with 4.2, because GWeck talked about a version for 4.2, but maybe I misunderstood.