Windows support in Qubes

I would suggest the following command for installation instead:

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

No extra steps required.

2 Likes

I would really appreciate a “Community Guides” contribution about installing Windows 10/11 on Qubes OS 4.2.

Edit: I installed Windows 10 Pro successfully following the existing guide: http://qubesosfasa4zl44o4tws22di6kepyzfeqv3tg4e3ztknltfxqrymdad.onion/doc/templates/windows/windows-qubes-4-1/

Worked on QubesOS 4.2. I will try the Qubes Windows Tools, soon.

So, am I understanding this QSB right: This security concern ONLY affects the Windows qube that uses the Qubes Windows Tools (QWT) and the Xen windows PV drivers. This doesn’t cause a dom0 compromise, nor the vulnerability to spread to other non-Windows domU qubes. Am I understanding this right?

If so, I can consider using the existing QWT and the Xen Windows PV drivers, as I won’t be doing any InfoSec-sensitive computing in the Windows qube anyways (will be used mainly for interacting with computer-normies that insist on using zoom, etc.).

That’s how I understand the QSB. Here’s what the impact section says:

Impact
-------

If the Xen Project's Windows PV Drivers were compromised at build time,
all Windows qubes that have Qubes Windows Tools (QWT) installed may also
be compromised. If the drivers were not compromised at build time, then
there is no known vulnerability.

Dom0 is not affected, even though the `qubes-windows-tools` package is
installed in dom0, since neither the dom0 package build process nor dom0
itself interprets these driver files. Rather, the purpose of this
package is merely to make the driver files available to the Windows
qubes in which QWT are installed.

It doesn’t say anything about dom0 or other qubes (that don’t have QWT) being affected. (In fact, it explicitly says that dom0 is not affected.)

2 Likes

In Windows (just as in Linux) only 2 protection rings are used. IOW, instead of running the device drivers in their own ring (which the x86 hardware allows), both OS simply run them in kernel mode. Although para-virtualization, which Qubes OS generally uses for isolation, prevents direct access to hardware from inside the VM, and we have IOMMU (aka VT-d) too, I wonder what exactly a compromised driver means and what actual effects it may have. (especially, considering not every Qubes OS user has Intel ME disabled and FOSS BIOS)

1 Like

Thanks for the hint! I’ve updated the text and added a warning about dom0 updates destroying the older version.

1 Like