-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Xen Security Advisory CVE-2018-3620,CVE-2018-3646 / XSA-273 L1 Terminal Fault speculative side channel ISSUE 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 IMPACT ====== 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). VULNERABLE SYSTEMS ================== Systems running all versions of Xen are affected. Only x86 processors are vulnerable. ARM processors are not known to be affected. Only Intel Core based processors (from at least Merom onwards) are potentially affected. Other processor designs (Intel Atom/Knights range), and other manufacturers (AMD) are not known to be affected. x86 PV guests fall into the CVE-2018-3620 (OS and SMM) category. x86 HVM and PVH guests fall into the CVE-2018-3646 (Hypervisors) category. MITIGATION ========== This issue can be mitigated with a combination of software and firmware changes. Switching guests to being HVM with shadow paging enabled (hap=0 in xl.cfg) is believed to mitigate the vulnerability on systems which don't have terabytes of RAM. However the performance impact of shadow paging in combination with in-guests Meltdown mitigations (KPTI, KVAS, etc) will most likely make this option prohibitive to use. RESOLUTION ========== New microcode, and possibly a new firmware image is required to prevent SMM data from being leaked with this vulnerability. Consult your hardware vendor. Software updates to Xen (details below) are required to prevent guests from being able to leak data belonging to Xen or to other guests in the system. Guest kernel software updates are required to prevent guest userspace from being able to leak data belonging to the kernel or other processes within the same guest. Consult your OS vendors. 1) For PV guests (which fall into the CVE-2018-3620 - OS/SMM case), leakage of data from Xen or other guests can be prevented entirely with software changes in Xen. If the PV guest tries to write an L1TF-vulnerable PTE (for current kernels, very likely when paging data out to disk), shadow paging is activated and forced upon the guest. Alternatively, if shadow paging is compiled out, the guest is crashed instead. Shadowing comes with a workload-dependent performance hit to the guest. Once the guest kernel software updates have been applied, a well behaved guest will not write vulnerable PTEs, and will therefore avoid the performance penalty (or crash) entirely. This behaviour is active by default for guests on affected hardware (controlled by `pv-l1tf=`), but is disabled by default for dom0. Dom0's exemption is because of instabilities when being shadowed, which are under investigation, but dom0 kernel updates should still be taken to mitigate the userspace aspect. 2) For HVM and PVH guests running with Hardware Assisted Paging (which fall into the CVE-2018-3646 - Hypervisors case), leakage of data from Xen or other guests can only be prevented entirely by disabling SMT/Hyper-threading (if available and active in the BIOS), and by using the L1D_FLUSH feature (available in the new microcode) on every VMEntry. On affected hardware, L1D_FLUSH is enabled by default (controlled by `spec-ctrl=[no-]l1d-flush`), subject to microcode availability. However, SMT/Hyper-threading is not disabled by default, because Xen does not have enough information to choose an appropriate default. Safety can be arranged in a number of ways by the toolstack, including with finer granularity than simply on or off. Therefore, users are expected to perform a risk assessment of their deployment, and explicitly chose a default (`smt=`). See the RISK ASSESSMENT section below. Xen will issue a warning at boot on vulnerable hardware when no explicit smt choice has been set. There are ongoing experimentation and development efforts to find lower overhead mitigations for the HVM case. We are not supplying separate patches because the changes have many complicated prerequisites. To get the fixes, it is necessary to update to the latest Xen applicable staging-XX branch. The relevant git commit object ids are as follows: d757c29ffe2e31b15397e43cd58da88b6318b654 staging-4.11 13e85a6dbc1eeda4f95c0d3afcd205579eab5909 staging-4.10 14f90aaef8d441cbdece5b74829e85e767fb196c staging-4.9 d95b5bb31e6d4361e356f0ff0853b6bb172a8b6a staging-4.8 9b8375a272ad02d8d0c229b3e3e7989e852734d8 staging-4.7 e1b03b03b199bd206c81286b4f51b6a681123eda staging-4.6 aa67b97ed34279c43a43d9ca46727b5746caa92e staging # xen-unstable In each case the tip commit is "xl.conf: Add global affinity masks". RISK ASSESSMENT OF SMT/HYPER-THREADING ====================================== 1) If hyper-threading is unavailable, or already disabled in the BIOS, no further action is necessary. 2) If you are using exclusively PV or HVM Shadow guests, hyper-threading has no impact on security, and is safe to remain enabled. 3) If an HVM guest kernel is trusted (i.e. under host admin control), and has been updated to include the OS vendor mitigations, then it is probably safe to be scheduled with hyper-threading active. 4) If an HVM guest kernel is untrusted (i.e. not under host admin control), it is probably not safe to be scheduled with hyper-threading active. FINER GRAINED SMT/HYPER-THREADING CONTROL WITH TOOLSTACK SETTINGS ================================================================= New options (vm.cpumask, vm.hvm.cpumask and vm.pv.cpumask) have been added in the xl/libxl toolstack to provide global control over CPU hard affinity settings. The global masks are applied when a guest is created or when a vcpu is pinned. Sketch of how to use the new options: 1. Livepatch the hypervisor. 2. Identify all sibling threads and partition them with the new options in xl.conf. 3. For each DomU, run `xl vcpu-pin $DOM all all`, which should cause the global masks to be applied to all vcpus of a DomU. 4. Verify the required affinity has taken effect by running `xl vcpu-list`. The default behaviour of xl is to always apply global masks unless `--ignore-global-affinity-masks` is specified. Please refer to xl.conf(5) for details. NOTE CONCERNING CVE-2018-3615 ============================= CVE-2018-3615 covers the interaction of L1TF and Intel SGX. Xen has no support for enclaves in any currently released version, so no Xen systems are affected. NOTE REGARDING LACK OF EMBARGO ============================== Despite an attempt to organise predisclosure, the discoverers ultimately did not authorise a predisclosure. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBCAAGBQJbcw4zAAoJEIP+FMlX6CvZZ0AIAMqgsxv05j191DxrphhMPgLT 9LybN7bCQU4z5bhufI0DQdppVU/WmAqhlVHL/Q9OJO1nnlTuGI0demuaObTnL6q0 HSNeC5ZArKT24qunr9hSzysG8LS5HI9lsIxYYz4FOSFOK6kn5MuQj5Z+ZdID/XTx 9/S21UfDvZPLhbxyqXmLfENzVkVOf+6NA/Ebl+0//sfbq/QtZAA0k63t3ZWatTPV 1heFGkb3Agmq5D/wtoKfcVbCmg2CU41/T9kXk4j1ADmIRc0FLjV/bXP16PC/XByP a+HmSG+nIWkYBpqYhDBu9M6lXeZb9bi2Oeh16FRuF5l28BbZcp3Zk19VUoSkgi4= =NRkR -----END PGP SIGNATURE-----