-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Xen Security Advisory CVE-2018-3639 / XSA-263 Speculative Store Bypass ISSUE DESCRIPTION ================= Contemporary high performance processors may use a technique commonly known as Memory Disambiguation, whereby speculative execution may proceed past unresolved stores. This opens a speculative sidechannel in which loads from an address which have had a recent store can observe and operate on the older, stale, value. For more details, see: https://bugs.chromium.org/p/project-zero/issues/detail?id=1528 https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00115.html https://www.amd.com/securityupdates IMPACT ====== An attacker who can locate or create a suitable code gadget in a different privilege context may be able to infer the content of arbitrary memory accessible to that other privilege context. At the time of writing, there are no known vulnerable gadgets in the compiled hypervisor code. Xen has no interfaces which allow JIT code to be provided. Therefore we believe that the hypervisor itself is not vulnerable. Additionally, we do not think there is a viable information leak by one Xen guest against another non-cooperating guest. However, in most configurations, within-guest information leak is possible. Mitigation for this generally depends on guest changes (for which you must consult your OS vendor) *and* on hypervisor support, provided in this advisory. VULNERABLE SYSTEMS ================== Systems running all versions of Xen are affected. Processors from all vendors are affected to different extents. Further communication will be made for Arm. See https://developer.arm.com/support/arm-security-updates/speculative-processor-vulnerability for more details. MITIGATION ========== This issue can be mitigated with a combination of software and firmware changes. RESOLUTION ========== This is a hardware bug. The primary mitigation in Xen context is modification of guests, especially JITs in guests, to avoid generating vulnerable code. Such modifications do not require support from Xen. Alternatively, the following patches provide some workarounds: On AMD hardware, for Fam15h processors and later, the patches offer a host-wide global control for whether Memory Disambiguation is enabled (default) or disabled. Controls are not virtualised for guests. When the global control is set to disabled (`spec-ctrl=ssbd' on the hypervisor command line), the vulnerability is eliminated without the need for other guest or hypervisor changes. On Intel hardware, a microcode update is required in order to work around the problem by disabling memory disambiguation. Consult your hardware vendor or your dom0 OS distributor for the firmware/microcode update. With the microcode update in place, the patches offer a host-wide control (which would eliminate the vulnerability on the whole system without guest changes), and virtualised controls for guests to use (which addresses the issue in a guest-specific manner). Consult your guest operating system vendors, for further information and advice. (Additionally, host firmware may be vulnerable and may require updates for that reason. Consult your hardware vendor.) xsa263-unstable/*.patch xen-unstable xsa263-4.10/*.patch Xen 4.10.x xsa263-4.9/*.patch Xen 4.9.x xsa263-4.8/*.patch Xen 4.8.x xsa263-4.7/*.patch Xen 4.7.x xsa263-4.6/*.patch Xen 4.6.x @maintainer(s): In case of bump, please call for stabilization when ready. Gentoo Security Padawan (domhnall)
Also known as Spectre Variant 3a. Adding kernel@ because this isn't simply a matter for Xen users. These are the earliest mainline kernel releases in which mitigating patches started to appear: * 4.4.144 * 4.9.102 * 4.14.43 * 4.16.11 # cat /sys/devices/system/cpu/vulnerabilities/spec_store_bypass Mitigation: Speculative Store Bypass disabled via prctl and seccomp
Sorry, Variant 4, not 3a. It's getting harder to keep track of them all :(
>=4.17 can be added to the aforementioned list of kernels. Also, note the new "spec_store_bypass_disable" parameter, per https://www.kernel.org/doc/html/latest/admin-guide/kernel-parameters.html.
QEMU 3.0 provides support for the "ssbd" CPUID flag. See also bug 664052.
I've requested that the patch to support ssbd be backported to qemu-2.12 - and have attached said patch - in bug 664054.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=55679e9cfb47c803931db687f2e3f510d66d91d1 commit 55679e9cfb47c803931db687f2e3f510d66d91d1 Author: Matthias Maier <tamiko@gentoo.org> AuthorDate: 2018-08-19 17:37:22 +0000 Commit: Matthias Maier <tamiko@gentoo.org> CommitDate: 2018-08-19 17:37:22 +0000 app-emulation/qemu: drop version 2.11.* Bug: https://bugs.gentoo.org/663502 Package-Manager: Portage-2.3.47, Repoman-2.3.10 app-emulation/qemu/Manifest | 2 - .../qemu/files/qemu-2.11.0-glibc-2.27.patch | 54 -- app-emulation/qemu/qemu-2.11.1-r2.ebuild | 805 --------------------- 3 files changed, 861 deletions(-)
This has been patched in 2018. NO GLSA
