Apr 13, 2024, 15:26 by a...@qubes-os.org: > On 4/13/24 8:15 AM, jmake2 via qubes-devel wrote: > >> Apr 13, 2024, 06:46 by a...@qubes-os.org: >> >>> On 4/12/24 4:50 AM, Gerhard Weck wrote: >>> >>>> [...] >>>> >>>> - Things may look different, if an attacker could, via the Xen PV drivers, >>>> break out of a Windows VM with QWT and compromise Xen, and therefore Qubes >>>> itself. In this case, usage of a Windows VM with the insecure QWT may be >>>> too risky in many, but not all circumstances. So far, I found no >>>> information, if such a scenario is possible at all. What is the extent of >>>> possible compromises of the Xen PV drivers - is it just local to the VM or >>>> could it reach into Qubes itself? It would be helpful if this could be >>>> clarified somehow. >>>> >>>> [...] >>>> >>> >>> This was already clearly addressed in QSB-091: >>> >>>> 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. >>>> >>> >>> In other words, only the Windows VMs using QWT are potentially at risk, not >>> dom0, Xen, or Qubes OS itself. >>> >> >> >> @adw , thank you. So, QWT does not directly affect security of dom0 nor >> other non-windows qubes. >> >> Please also tell if QWT is deprecated, as unman kind of said, or not? >> > > This is also addressed in QSB-091: > >> At the time of writing, the Xen Project has not published replacement >> binaries signed by a Microsoft-approved key. The process for doing this >> has changed since the last version of Windows PV Drivers was released, >> and we have no information as to whether or when new signed binaries >> will be available. [2] >> >> In order to avoid similar problems in the future, we are working on a >> more permanent solution regarding the need for signed PV drivers in QWT. >> In the meantime, we will replace the `qubes-windows-tools` package with >> a dummy package containing only warning text. >> > > https://www.qubes-os.org/news/2023/07/27/qsb-091/ >
Well, the link does not say the QWT is deprecated in any way. The only problem is that Qubes OS was not building some drivers using in QWT from sources but used Xen's binaries that are signed with Microsoft-approved key. Now Microsoft deprecated this way of signing, that's all. Deprecated signing approach by Microsoft have nothing to do with deprecation of available Xen drivers sources, nor QWT itself, if I am getting it correctly (I hope). So, am I getting it right that QWT is not deprecated? I was afraid for a moment. As it was discussed previously, the QWT package can be build from secure and available sources and put to R4.2+ repos with different signatures, including secure self-signed but not Microsoft-approved key. Requirement to allow self-signed drivers is not perfect, but still a way better solution than current situation, to my understanding. I support the opinion that R4.1 cannot be EOLed before there would be a version of Qubes OS that is capable to restore and boot such windows qubes with valuable users' data in them. -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/NvNA3sG--3-9%40tutanota.com.
