Comment 13 for bug 1548450

At first glance, I think live migration is vulnerable. pre_live_migration runs on the destination host, and runs _create_images_and_backing() without having copied over disk.info. _create_images_and_backing is passed disk_info (not to be confused with disk.info) which was originally generated by libvirt.get_instance_disk_info on the source host. This disk_info is going to correctly identify the ephemeral disk as not having a backing file. It will create a blank disk of the correct format (raw) and size at the destination. The live migration process will then copy over the malicious bits to the blank disk, and the guest will run on the destination host using xml taken from the source host, which again will contain the correct backing information. However, as far as I can see, disk.info still does not exist on the destination at this point.

If the user reboots, _hard_reboot will regenerate the guest xml. Through a long chain of calls, this will result in a call to libvirt._get_guest_disk_config for the ephemeral disk. This calls imagebackend.image(), which instantiates a Raw object. That instantiation calls correct_format(), which calls resolve_driver_format(), which sees that there is no disk.info, inspects the disk and incorrectly reports it as qcow2 with the malicious backing file. At this point, the user can access the backing file.

Long story short: pre_live_migration should probably also copy disk.info.