This update for kvm fixes the following issues:
This update has the next round of Spectre v2 related patches, which now integrates with corresponding changes in libvirt. A January 2018 release of qemu initially addressed the Spectre v2 vulnerability for KVM guests by exposing the spec-ctrl feature for all x86 vcpu types, which was the quick and dirty approach, but not the proper solution. We remove that initial patch and now rely on patches from upstream. This update defines spec_ctrl and ibpb cpu feature flags as well as new cpu models which are clones of existing models with either -IBRS or -IBPB added to the end of the model name. These new vcpu models explicitly include the new feature(s), whereas the feature flags can be added to the cpu parameter as with other features. In short, for continued Spectre v2 protection, ensure that either the appropriate cpu feature flag is added to the QEMU command-line, or one of the new cpu models is used. Although migration from older versions is supported, the new cpu features won't be properly exposed to the guest until it is restarted with the cpu features explicitly added. A reboot is insufficient.
A warning patch is added which attempts to detect a migration from a qemu version which had the quick and dirty fix (it only detects certain cases, but hopefully is helpful.)
For additional information on Spectre v2 as it relates to QEMU, see: https://www.qemu.org/2018/02/14/qemu-2-11-1-and-spectre-update/
(CVE-2017-5715 bsc#1068032)
A patch is added to continue to detect Spectre v2 mitigation features (as shown by cpuid), and if found provide that feature to guests, even if running on older KVM (kernel) versions which do not yet expose that feature to QEMU. (bsc#1082276)
Additional security fixes:
CVE-2017-18030: An out-of-bounds access in cirrusinvalidateregion routine could lead to crashes or information leakage (bsc#1076179)
Eliminate bogus use of CPUID70EDXPREDCMD which we've carried since the initial Spectre v2 patch was added. EDX bit 27 of CPUID Leaf 07H, Sub-leaf 0 provides status on STIBP, and not the PREDCMD MSR. Exposing the STIBP CPUID feature bit to the guest is wrong in general, since the VM doesn't directly control the scheduling of physical hyperthreads. This is left strictly to the L0 hypervisor.