make that determination manually. This tool is included in the `qubes-core-dom0-linux-4.0.35` package for Qubes 4.0 and the `qubes-core-dom0-linux-4.1.23` package for Qubes 4.1. These packages will migrate from the security-testing repository to the current (stable) repository over the next two weeks after being tested by the community. [1] Once available, the packages are to be installed via the Qubes Update tool or its command-line equivalents. [2] After installing the required updates, you will be able to execute `sudo cpu-microcode-info` in a dom0 terminal. This will output a table of information about the logical CPUs (aka CPU "cores") in your system. The "F-M-S/PI" column lists the "Family-Model-Stepping/Platform ID" codes that Intel uses in its microcode documentation, [5] which is explained in further detail in Intel's README. [6] (The manual process of checking would involve extracting your CPU information, converting it to hexadecimal, and looking it up in the appropriate table in this document.) The "Loaded microcode version" column lists the microcode versions currently loaded for each CPU. The "20220510 update available" column lists whether the required May 2022 microcode update is *available* for each CPU. The "20220510 update installed" column lists whether the required May 2022 microcode update is *installed* in each CPU. In order for the updates associated with this bulletin to successfully mitigate XSA-404, a value of "yes" is required in both of these last two "20220510 update" columns. If the "available" column has a "yes" while the "installed" column has a "no," then the May 2022 microcode update must be installed first. If both columns have "no" values, then this CPU remains vulnerable, and there is no known mitigation available. If your system has such a CPU, then installing The Xen packages listed in the "user action required" section above is *not* expected to mitigate the problem described in this bulletin. Unfortunately, there is simply nothing we can do for these CPUs in terms of patching unless we receive a fix from Intel or receive new information about which CPUs are affected. Nonetheless, we still recommend installing the updates anyway (once available), since they will not make the problem any worse, keeping up-to-date with all security updates is a general best practice, and future updates will be based on the latest version. However, hope is not entirely lost for users whose CPUs are not eligible for software mitigations. Since the vulnerability discussed in this bulletin does not affect VMs without PCI passthrough devices, users still have the option of altering their habits to treat VMs like sys-usb and sys-net as more trusted. While this can be especially challenging in the case of sys-net, it at least affords users *some* latitude in working around the problem by being mindful of when such VMs are running, how trusted their templates are, and similar considerations. Further plans regarding PCI passthrough ---------------------------------------- This is yet another issue affecting only VMs with access to PCI devices. This pattern of vulnerabilities has prompted us to research more secure ways of handling such VMs in future Qubes releases. Eventually, we plan to treat them as more privileged VMs that require additional protection. Specific protective measures will be discussed with the community as part of our ongoing research and development efforts. Credits -------- See the original Xen Security Advisory. References ----------- [1] https://www.qubes-os.org/doc/testing/ [2] https://www.qubes-os.org/doc/how-to-update/ [3] https://xenbits.xen.org/xsa/advisory-404.html [4] www.intel.com/content…del.html [5] github.com/intel/I…enote.md