Dear Qubes Community,
We have just published Qubes Security Bulletin (QSB) #43: L1 Terminal Fault speculative side channel (XSA-273). The text of this QSB is reproduced below. This QSB and its accompanying signatures will always be available in the Qubes Security Pack (qubes-secpack).
View QSB #43 in the qubes-secpack:
Learn about the qubes-secpack, including how to obtain, verify, and read it:
View all past QSBs:
View XSA-273 in the XSA Tracker:
---===[ Qubes Security Bulletin #43 ]===--- 2018-09-02 L1 Terminal Fault speculative side channel (XSA-273) Summary ======== On 2018-08-14, the Xen Security Team published Xen Security Advisory 273 (CVE-2018-3620,CVE-2018-3646 / XSA-273)  with the following description: | In x86 nomenclature, a Terminal Fault is a pagetable walk which aborts | due to the page being not present (e.g. paged out to disk), or because | of reserved bits being set. | | Architecturally, such a memory access will result in a page fault | exception, but some processors will speculatively compute the physical | address and issue an L1D lookup. If data resides in the L1D cache, it | may be forwarded to dependent instructions, and may be leaked via a side | channel. | | Furthermore: | * SGX protections are not applied | * EPT guest to host translations are not applied | * SMM protections are not applied | | This issue is split into multiple CVEs depending on circumstance. The | CVEs which apply to Xen are: | * CVE-2018-3620 - Operating Systems and SMM | * CVE-2018-3646 - Hypervisors | | For more details, see: | https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00161.html | | An attacker can potentially read arbitrary host RAM. This includes data | belonging to Xen, data belonging to other guests, and data belonging to | different security contexts within the same guest. | | An attacker could be a guest kernel (which can manipulate the pagetables | directly), or could be guest userspace either directly (e.g. with | mprotect() or similar system call) or indirectly (by gaming the guest | kernel's paging subsystem). This is yet another CPU hardware bug related to speculative execution. Only Intel processors are affected. Impact of mitigations on Qubes OS ================================== Qubes OS 3.2 ------------- Part of the mitigation is to disable hyper-threading. This halves the number of CPU cores that the system sees compared to having hyper-threading enabled, thus reducing system performance. This mitigation is needed only when running HVM qubes (or PVH, but PVH is not available in Qubes OS 3.2 anyway). However, we believe there is a risk that similar issues will be discovered in the future, and that having hyper-threading disabled may mitigate those issues, as it does this one. Therefore, we recommend that most users leave hyper-threading disabled regardless of whether they use HVM qubes. If you decide that you are willing to accept the risks of enabling hyper-threading, you can do so by following the instructions below. The instructions differ depending on whether you use EFI or legacy boot. How to re-enable hyper-threading with EFI boot: 1. Change `smt=off` to `smt=on` in `/boot/efi/EFI/qubes/xen.cfg` in dom0. 2. Save your change to the file. 3. Reboot dom0. How to re-enable hyper-threading with legacy boot: 1. Change `smt=off` to `smt=on` in `/etc/default/grub` in dom0. 2. Save your change to the file. 3. Run `sudo grub2-mkconfig -o /boot/grub2/grub.cfg` in dom0. 4. Reboot dom0. Qubes OS 4.0 ------------- Part of the mitigation is to disable hyper-threading. This halves the number of CPU cores that the system sees compared to having hyper-threading enabled, thus reducing system performance. Since Qubes OS 4.0 uses both PVH and HVM qubes, it is _not_ safe to re-enable hyper-threading. If you have previously modified the number of virtual CPUs assigned to any qube (the "vcpus" property), it may be necessary to adjust this value in order to account for reduced system performance. In addition, if you use any PV qubes (which is discouraged for security reasons), it is necessary to update their kernels to a version that contains L1TF mitigations. Otherwise, they may crash when using swap, which is part of the L1TF mitigation and (partially) due to the intentional  lack of shadow paging support in Qubes OS 4.0. If the kernel is provided by dom0 (the "kernel" property), we provide updated kernel packages (see the "Patching" section below). If the kernel is used from within the VM (using pvgrub), use the VM's appropriate distribution update channel. Alternatively, to avoid crashing, you can disable swap in such VMs. Patching ========= The Xen Project has provided patches that mitigate this issue. A CPU microcode update is required to take advantage of them. The specific packages that resolve the problems discussed in this bulletin are as follows: For Qubes 3.2: - Xen packages, version 4.6.6-44 - microcode_ctl package, version 2.1-26.qubes1 - kernel-qubes-vm package, version 4.14.67-1 For Qubes 4.0: - Xen packages, version 4.8.4-2 - microcode_ctl 2.1-26.qubes1 - kernel-qubes-vm package, version 4.14.67-1 (optional) The packages are to be installed in dom0 via the Qubes VM Manager or via the qubes-dom0-update command as follows: For updates from the stable repository (not immediately available): $ sudo qubes-dom0-update For updates from the security-testing repository: $ sudo qubes-dom0-update --enablerepo=qubes-dom0-security-testing A system restart will be required afterwards. 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. If you use Anti Evil Maid, you will need to reseal your secret passphrase to new PCR values, as PCR18+19 will change due to the new Xen binaries. Credits ======== See the original Xen Security Advisory. References ===========  https://xenbits.xen.org/xsa/advisory-273.html  https://www.qubes-os.org/news/2016/07/21/new-hw-certification-for-q4/ -- The Qubes Security Team https://www.qubes-os.org/security/