As CVE-2017-5715 described on https://access.redhat.com/security/cve/cve-2017-5715, libvirt under the influence yet, So what's coming next for this? Signed-off-by: Wang King <king.wang@huawei.com> -- 2.8.3
On Thu, Jan 04, 2018 at 20:19:51 +0800, Wang King wrote:
As CVE-2017-5715 described on https://access.redhat.com/security/cve/cve-2017-5715, libvirt under the influence yet, So what's coming next for this?
We're waiting for QEMU patches since libvirt can't do much with this issue by itself. Jirka
On 01/04/2018 06:51 AM, Jiri Denemark wrote:
On Thu, Jan 04, 2018 at 20:19:51 +0800, Wang King wrote:
As CVE-2017-5715 described on https://access.redhat.com/security/cve/cve-2017-5715, libvirt under the influence yet, So what's coming next for this?
We're waiting for QEMU patches since libvirt can't do much with this issue by itself.
I'm by no means an expert on the topic, but from my cursory reading of the information made public yesterday, it was mentioned that one way to trigger the architectural exploit was across hypercalls; hence, the entire virtualization stack was listed as associated with the CVE (thus including libvirt), even if the patches for the issues will not be required against all affected software. Although a complete fix may be impossible without hardware changes, software mitigations may be added at various or multiple levels of the software stack to minimize the chance of the exploit being able to leak information that should have been protected by security boundaries. In particular, updating your kernel to include patches for Meltdown is an important step to take now, for any system where you have a vulnerable kernel running libvirt to manage untrusted guests; even though the kernel patch against Meltdown does not necessarily mitigate the Spectre aspects of the hardware vulnerabilities. One thing that might happen: the papers describing the flaws mention that side effects of speculative execution in hardware is a root cause for all three related vulnerabilities (two under the name Spectre and one under the name Meltdown) just made public; so it is conceivable that hardware vendors may offer a microcode update that enables run-time enabling/disabling of speculative execution (a tradeoff of speed vs. security; disabling speculative execution would prevent leaks, but kill performance). It may be that such hardware knobs will then have to have emulation counterpart knobs exposed in qemu, at which point libvirt XML may want to be enhanced to allow the end user a choice between which execution style to expose in an L1 guest (and thereby controlling the security of untrusted L2 guests being run by the L1 guest), similarly to how your host kernel would have a way to tweak such a knob at the hardware L0 execution layer for managing what can be leaked by hypercalls from L1 guests. But this is speculation on my part on what may be coming; the CVE references exist to document the hardware flaw and gracefully track any such software tweaks added for mitigating the hardware problem, even if no libvirt patches related to the CVE are currently in the pipeline. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org
On 01/04/2018 10:46 AM, Eric Blake wrote:
One thing that might happen: the papers describing the flaws mention that side effects of speculative execution in hardware is a root cause for all three related vulnerabilities (two under the name Spectre and one under the name Meltdown) just made public; so it is conceivable that hardware vendors may offer a microcode update that enables run-time enabling/disabling of speculative execution (a tradeoff of speed vs. security; disabling speculative execution would prevent leaks, but kill performance).
Indeed, that's part of what has already happened - Intel and AMD are both providing new microcode that adds new processor capability bits for controlling the use of speculative execution while executing kernel code; and part of the updates you will need to protect against Spectre include updating to that new microcode, updating the kernel to take advantage of the new processor capabilities, updating qemu to migrate the CPUID state of those new capabilities, and updating libvirt's CPU models to include those new CPUID states. For maximum protection, you have to update both host and guest kernels. The updates do come with performance penalties, so you will also want to benchmark what the updates will do to your deployments, and consider whether you have sufficient security via other means to avoid having to use the slowdowns entailed by generically disabling speculative execution in the kernel if you have a high-performance situation that is sufficiently isolated, vs. using the patches and taking the performance hit if you cannot ensure that no other process on the machine will ever attempt to abuse the effects of Spectre. More details can be learned from this blog post: https://www.qemu.org/2018/01/04/spectre/ And yes, there are still patches and updates coming down the pipeline (the embargo was lifted at a point when not all patches were fully baked), so if you are planning mass upgrades, be sure you factor in the availability of patches into your timeline. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org
participants (3)
-
Eric Blake -
Jiri Denemark -
Wang King