Switch branches/tags
w_49cc5d5a mm_78525939 mm_61621ebb mm_51660c83 mm_15143d72 mm_692db79a mm_201e4cc3 mm_109b6fdf mm_89af9f06 mm_49cc5d5a mm_40b3338e mm_7c825880 mm_5f208b29 mm_3bd7fe2e mm_2beab537 mm_1e390705 mm_d9c2f7df mm_d5a7241a mm_a4e175f3 marmarek_sec_84308824 marmarek_sec_78525939 marmarek_sec_46658321 marmarek_sec_24681439 marmarek_sec_6325034c marmarek_sec_4472371a marmarek_sec_539649d9 marmarek_sec_0311584c marmarek_sec_287158a9 marmarek_sec_162930b6 marmarek_sec_81194e72 marmarek_sec_61621ebb marmarek_sec_51660c83 marmarek_sec_43373e67 marmarek_sec_42521f68 marmarek_sec_15143d72 marmarek_sec_9097bd53 marmarek_sec_9038afac marmarek_sec_8487a05e marmarek_sec_6945bc33 marmarek_sec_6613fd2b marmarek_sec_5539bfe8 marmarek_sec_4506ce8d marmarek_sec_2245aeed marmarek_sec_1302b8c6 marmarek_sec_880c1d9d marmarek_sec_848e7753 marmarek_sec_813f2ae3 marmarek_sec_806ab1a4 marmarek_sec_786ae750 marmarek_sec_735d08c4 marmarek_sec_696e531c marmarek_sec_692db79a marmarek_sec_688f1623 marmarek_sec_201e4cc3 marmarek_sec_160b7a0b marmarek_sec_113cf714 marmarek_sec_109b6fdf marmarek_sec_97f1428a marmarek_sec_93f129d7 marmarek_sec_91c22ed5 marmarek_sec_89af9f06 marmarek_sec_85d18bac marmarek_sec_81ac5fe4 marmarek_sec_77c18513 marmarek_sec_71eeb2ea marmarek_sec_68fa5cee marmarek_sec_66c7326e marmarek_sec_65c0e16e marmarek_sec_64f3338c marmarek_sec_55f7b189 marmarek_sec_55a292c9 marmarek_sec_49cc5d5a marmarek_sec_45f79323 marmarek_sec_41b90963 marmarek_sec_40b3338e marmarek_sec_35d7e6f1 marmarek_sec_33c90326 marmarek_sec_22c5fe0d marmarek_sec_20fc0746 marmarek_sec_16c2b497 marmarek_sec_15ac3d41 marmarek_sec_9ffb5883 marmarek_sec_9f43f503 marmarek_sec_9e64bee1 marmarek_sec_9d85918c marmarek_sec_9d2ab5db marmarek_sec_9ce311f5 marmarek_sec_8e412587 marmarek_sec_8db2fb5d marmarek_sec_7f76bce3 marmarek_sec_7cdffb89 marmarek_sec_7bea266a marmarek_sec_7b063902 marmarek_sec_6be15b69 marmarek_sec_5fb232ea marmarek_sec_5f208b29 marmarek_sec_5e61a5a6 marmarek_sec_5ddbd92b marmarek_sec_5c986968 marmarek_sec_5c9616cd
Nothing to show
Find file Copy path
Fetching contributors…
Cannot retrieve contributors at this time
158 lines (122 sloc) 5.65 KB
---===[ Qubes Security Bulletin #43 ]===---
L1 Terminal Fault speculative side channel (XSA-273)
On 2018-08-14, the Xen Security Team published Xen Security Advisory
273 (CVE-2018-3620,CVE-2018-3646 / XSA-273) [1] with the following
| 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:
| 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 [2] 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.
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.
See the original Xen Security Advisory.
The Qubes Security Team