---===[ 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) [1] 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 [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.

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
===========

[1] https://xenbits.xen.org/xsa/advisory-273.html
[2] https://www.qubes-os.org/news/2016/07/21/new-hw-certification-for-q4/

--
The Qubes Security Team
https://www.qubes-os.org/security/