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
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
