[libvirt] About CVE-2017-5715

Eric Blake eblake at redhat.com
Thu Jan 4 16:46:48 UTC 2018


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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 619 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20180104/e4057644/attachment-0001.sig>


More information about the libvir-list mailing list