I would suggest the following command for installation instead:
sudo qubes-dom0-update qubes-windows-tools-4.1.69
No extra steps required.
I would suggest the following command for installation instead:
sudo qubes-dom0-update qubes-windows-tools-4.1.69
No extra steps required.
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.)
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)
Thanks for the hint! Iâve updated the text and added a warning about dom0 updates destroying the older version.