Re: [qubes-users] QSB #43: L1 Terminal Fault speculative side channel (XSA-273)

2018-09-02 Thread taii...@gmx.com
Yet another reason to port qubes to POWER - the last owner controlled
performance CPU arch.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/f7f2072f-2b4e-7fa5-c1f3-9afe29b88088%40gmx.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] QSB #43: L1 Terminal Fault speculative side channel (XSA-273)

2018-09-01 Thread Andrew David Wong
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

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:

https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-043-2018.txt

Learn about the qubes-secpack, including how to obtain, verify, and read
it:

https://www.qubes-os.org/security/pack/

View all past QSBs:

https://www.qubes-os.org/security/bulletins/

View XSA-273 in the XSA Tracker:

https://www.qubes-os.org/security/xsa/#273

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