-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Xen Security Advisory CVE-2018-12126,CVE-2018-12127,CVE-2018-12130,CVE-2019-11091 / XSA-297 Microarchitectural Data Sampling speculative side channel ISSUE DESCRIPTION ================= Microarchitectural Data Sampling refers to a group of speculative sidechannels vulnerabilities. They consist of: * CVE-2018-12126 - MSBDS - Microarchitectural Store Buffer Data Sampling * CVE-2018-12127 - MLPDS - Microarchitectural Load Port Data Sampling * CVE-2018-12130 - MFBDS - Microarchitectural Fill Buffer Data Sampling * CVE-2019-11091 - MDSUM - Microarchitectural Data Sampling Uncacheable Memory These issues pertain to the Load Ports, Store Buffers and Fill Buffers in the pipeline. The Load Ports are used to service all memory reads. The Store Buffers service all in-flight speculative writes (including IO Port writes), while the Fill Buffers service all memory writes which are post-retirement, and no longer speculative. Under certain circumstances, a later load which takes a fault or assist (an internal condition to processor e.g. setting a pagetable Access or Dirty bit) may be forwarded stale data from these buffers during speculative execution, which may then be leaked via a sidechannel. MDSUM (Uncacheable Memory) is a special case of the other three. Previously, the use of uncacheable memory was believed to be safe against speculative sidechannels. For more details, see: https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00233.html IMPACT ====== An attacker, which could include a malicious untrusted user process on a trusted guest, or an untrusted guest, can sample the content of recently-used memory operands and IO Port writes. This can include data from: * A previously executing context (process, or guest, or hypervisor/toolstack) at the same privilege level. * A higher privilege context (kernel, hypervisor, SMM) which interrupted the attacker's execution. Vulnerable data is that on the same physical core as the attacker. This includes, when hyper-threading is enabled, adjacent threads. An attacker cannot use this vulnerability to target specific data. An attack would likely require sampling over a period of time and the application of statistical methods to reconstruct interesting data. VULNERABLE SYSTEMS ================== Systems running all versions of Xen are affected. Only x86 processors are vulnerable. ARM processors are not believed to be vulnerable. Only Intel based processors are potentially affected. Processors from other manufacturers (eg, AMD) are not believed to be vulnerable. Please consult the Intel Security Advisory for details on the affected processors, and which are getting microcode updates. MITIGATION ========== This issue can be mitigated with a combination of software, firmware and configuration changes. Note that some affected processors are not expected to receive microcode updates. For these processors, there is no mitigation available. Users with workloads of concern on these processors should see about moving the workload elsewhere. 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. The microcode update alone may be packaged for boot-time loading. Consult your dom0 OS vendor. Software updates to Xen (details below) are required to prevent data leakage from Xen into lower privileged contexts. Leakage of data from Xen or other guests can only prevented entirely by disabling hyper-threading (if available and active in the BIOS), and by applying the patches to Xen. The Xen patches use the MD_CLEAR feature (available in the new microcode) on every exit to guest. On affected hardware, MD_CLEAR is used by default (controlled by `spec-ctrl=[no-]md-clear`), subject to microcode availability. Note: For compatibility with development versions of this fix, `spec-ctrl=[no-]mds` is also accepted on Xen 4.12 and earlier as an alias. Consult vendor documentation in preference to here. The availability of the MD_CLEAR functionality in microcode is reported by Xen on boot. e.g: [root@localhost ~]# xl dmesg | grep MD_CLEAR (XEN) Hardware features: IBRS/IBPB STIBP L1D_FLUSH SSBD MD_CLEAR (XEN) Support for HVM VMs: MSR_SPEC_CTRL RSB EAGER_FPU MD_CLEAR (XEN) Support for PV VMs: MSR_SPEC_CTRL RSB EAGER_FPU MD_CLEAR SMT/Hyper-Threading is not disabled by default because doing so is expected to be too disruptive to existing configurations. See the discussion concerning SMT/Hyper-Threading below. Guest software updates will be required to prevent data leakage within the guest, by making use of the new MD_CLEAR functionality at suitable points. Consult the vendors of all software used in the guest. xsa297/xsa297-unstable-*.patch xen-unstable xsa297/xsa297-4.12-*.patch Xen 4.12.x xsa297/xsa297-4.11-*.patch Xen 4.11.x xsa297/xsa297-4.10-*.patch Xen 4.10.x xsa297/xsa297-4.9-*.patch Xen 4.9.x xsa297/xsa297-4.8-*.patch Xen 4.8.x xsa297/xsa297-4.7-*.patch Xen 4.7.x $ sha256sum xsa297* xsa297*/* 242a4c9b24aeeac14b5f3e5069cd964c061072c52e63c3050a20986868a87a11 xsa297.meta f45354f35ba1726aa274443394e4e1669a518df3c8b62ec2ca24d4bfcf2f4b8e xsa297/xsa297-unstable-1.patch e5a0cbcbd07e5fb20d7dcdd14011281d19baa9c0d958520deede59f11aec3e46 xsa297/xsa297-unstable-2.patch c055646eabeb03f6c6d62e95e37fe705d7716a47936dbd65671bedaddad895f7 xsa297/xsa297-unstable-3.patch 9c2d4aa8122d3f8c109b32d707dae5d236f8df14e25db5db97743c29432bab75 xsa297/xsa297-unstable-4.patch af7758b080579e130a9f1bcc5dc6b4a67699a09a5d89280cc2f6c45e26d23ed7 xsa297/xsa297-4.7-1.patch 15d214c38db3f240687a06a07725d31929c942201a07b988b20ba9766d325321 xsa297/xsa297-4.7-2.patch ab16d609822712b6110867cd0179ade0f05ccb36e975cb8f7e711497b47813f5 xsa297/xsa297-4.7-3.patch b292aff757800ad8fa37b4db0035a2cf9a580ff8c99816059e0aba9e925f573d xsa297/xsa297-4.7-4.patch 15556852f8f62c4cb6019dd7731df31983b16076de6730a7a66defd3d0594927 xsa297/xsa297-4.7-5.patch 5308bbcc58b4811ff05fce60899e071e4fe3c9cade792fcc5c1c1b6d51001132 xsa297/xsa297-4.7-6.patch e9752a539d103c465342a1f87c92dcc8a099f34fc668413f7f134174f2bffc68 xsa297/xsa297-4.7-7.patch 9f22cbc56de9fb439c97aa48952ee0a0ebf92b78c135934270c40840961ddf89 xsa297/xsa297-4.7-8.patch b56828a7fb74529cc1cac152e2ee69df8de53c09676c14ca24823daf990b193a xsa297/xsa297-4.8-1.patch 34b04ff0a463c211b30c41048f4a448bd8d83123b426b4de695034b46c7b0952 xsa297/xsa297-4.8-2.patch 4db2dc7aa3dc3fd1ed30160bd686c9a4890351688feafd7e6e3317438bccd561 xsa297/xsa297-4.8-3.patch febf5797b67133f089baa39d710366eefff04d25438dbda051d33cdb78f59004 xsa297/xsa297-4.8-4.patch eb75795273cca3c29a883bdb499e8e33237ad016c41080e5eb6f9755334e35c9 xsa297/xsa297-4.8-5.patch 601cd6c6c805bf9200702806e6e807db04406f15487191d1d95c4521c5f3f860 xsa297/xsa297-4.8-6.patch dc3ef28a7b92788eb06a88d44ea8a1f1b72ef859ff46f6ff7c30376ae0ec17df xsa297/xsa297-4.8-7.patch a5dbc30dcc4bed0bf7ea77b73d9dab0c82e5efdc0a93569617b8e7e5221b3ca5 xsa297/xsa297-4.8-8.patch 10c9ec26d23360de805bc4439aee5766c22f12f6229b8ee5ea045d44cec79267 xsa297/xsa297-4.9-1.patch 34b04ff0a463c211b30c41048f4a448bd8d83123b426b4de695034b46c7b0952 xsa297/xsa297-4.9-2.patch da0d8c5f171379698f9a0cb030c2dda8f37153016da929457f318e4f8a0ee2bb xsa297/xsa297-4.9-3.patch 151822d5d60bfebc5df61de9a8593f504f6c25cf973a28dcb85e85c0416a0aed xsa297/xsa297-4.9-4.patch eb75795273cca3c29a883bdb499e8e33237ad016c41080e5eb6f9755334e35c9 xsa297/xsa297-4.9-5.patch 6636a0c92be892090522317c2b2145d2764168b50d4c1d964d2d52b3f33f54cf xsa297/xsa297-4.9-6.patch 226de265e8ebb535711f94fb9cc78802f97d092348fb6fb707c15d557659bae9 xsa297/xsa297-4.9-7.patch 44b05fe2fe7d340a6ebfdd61d3d59fb5255410269051b9bcf5bbf400e6712189 xsa297/xsa297-4.9-8.patch d05db34a8ee61f6762bb94b7c5c976364a3869fa7b70782a22dfb3c563c9d6c5 xsa297/xsa297-4.10-1.patch 6075a134a941cc83a9a7b2e428d7111857ab9bc5f3f75935a2f5d4cb7c7aca0d xsa297/xsa297-4.10-2.patch cc35f2c5d5c39120cbea0808b0772e9a3568fb45324023eb3192e9d4bea5dee0 xsa297/xsa297-4.10-3.patch eb75795273cca3c29a883bdb499e8e33237ad016c41080e5eb6f9755334e35c9 xsa297/xsa297-4.10-4.patch 5f2d3ac26e4fbde707cc7c5d398a3550f05ca4814d60b5ce9d5b6d95e7243a68 xsa297/xsa297-4.10-5.patch 9942f973f341a0d7e439f679fcdbcecc9828f6ca50e8b48ba914b5b40688039b xsa297/xsa297-4.10-6.patch c2e33bd9cdd696a71eae276b20eea8dc7e13e6013380ab20635a9931dd2bf1d4 xsa297/xsa297-4.10-7.patch 87e79a9c2a8fd385b3536b2935293dc3efcaca31523b8f2780be5d62cce4248f xsa297/xsa297-4.11-1.patch 57a63c120053a6bf76c1005735186ad477ea736354a2f60d5517b205f553f600 xsa297/xsa297-4.11-2.patch bb98de0ccdc74b6db6045cf4869da3788c83eaec12e4a9292293c409f94cd473 xsa297/xsa297-4.11-3.patch eb75795273cca3c29a883bdb499e8e33237ad016c41080e5eb6f9755334e35c9 xsa297/xsa297-4.11-4.patch d8aa296014cb15107668e351fd383e1dfd9af56a3d109725f7b5e1d9a2a7cf81 xsa297/xsa297-4.11-5.patch a28fb9f1cc84b8f91e2b53e629c7729bab60b41675720eb169d8172d9edf58f0 xsa297/xsa297-4.11-6.patch 8310358fb547c306b35762bf8b389700560e277f8d58f780f7215b3f78dfa4cc xsa297/xsa297-4.11-7.patch fd3a8d83645799e832767a43647b1255e2e0240ba9c40c6f661d27a08e880770 xsa297/xsa297-4.12-1.patch 6cf827a557c1993db9f7f1c08a8efc3e2ccb955fe2d59c0cadb1b3294d9bfed8 xsa297/xsa297-4.12-2.patch 14d47c1b448c3e81f773e7f762e6af682285d61ce8fade8902f52340cb77efab xsa297/xsa297-4.12-3.patch 891c181ce03b765795534e20004679bb102150d98c8db2b879a2cabe60689089 xsa297/xsa297-4.12-4.patch 1d17219413ca150e4815469481d19f044b1abcf3dc7f6824caccbc85b3a99702 xsa297/xsa297-4.12-5.patch 3fb437b18d9cba432c424331a083da52b3ad1ebf81fed3413315ee1d8117ca40 xsa297/xsa297-4.12-6.patch 71a8bfd370269bcd3520e8969a9c4fbedb75035e3eb4b12347ac08d67ccf91e0 xsa297/xsa297-4.12-7.patch $ DISCUSSION CONCERNING SMT/HYPER-THREADING ========================================= An attacker can perform an MDS-based attack from userspace, with unprivileged instructions. As the leakage occurs from stale data latched in buffers in the pipeline, the only defence is to flush the buffers before moving to a less privileged context. On affected processors when hyper-threading is enabled, the in-flight memory content from other threads can be observed, from whatever context is executing. This could be a different piece of userspace, or the guest kernel, or Xen. It could also be from a vcpu belonging to a different guest. Work is ongoing on xen-devel to develop core-aware scheduling, which will mitigate the cross-domain leak by ensuring that vcpus from different domains are never concurrently scheduled on sibling threads. However, this alone will not prevent cross-privilege level leakage from within the same domain, including leakage from Xen. If you have any untrusted code running in VMs, and need to prevent the risk of data leakage, the only available option at the moment is to disable hyper-threading. This is preferably done in the BIOS, but can also be done by Xen at boot time by specifying `smt=no` on the command line. NOTE REGARDING LACK OF EMBARGO ============================== Despite an attempt to organise predisclosure, the discoverers ultimately did not authorise a predisclosure. -----BEGIN PGP SIGNATURE----- iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAlza5AgMHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZYnYH/RMXGBcI79B0qD3lG19j8b//j8iDLskTHSkRg6HU 3UXMu1aAEqtgP3yoDl00vDKBMqfNygduQt5mf+nPgM3QDJi0tU9bkUjq+K+u5GQN wHj6HXneAtv7pQNo+VCO7JIXg0/XFVC/qLA44Edw9V3rZIq++LzWNQAtXmHs6xlx 0D2gq7B3hsz0ZkM7og9uPCFmkvwXbjq63f2SUmBw6u95lUThu3BDSkG87/HcqBDb n9MhvcIsy8cfvVt4A47UIPXm48MVQfH5a2Q8yTRK+Ix59vJ2QzAXn8N4WtksI0u6 YDgDihr7yU5xuQAU593Gbs5hOm9eDyTSY2jy0bwPlZb/Nf0= =XbSi -----END PGP SIGNATURE-----