libvirt: Always copy or recreate disk.info during a migration
The disk.info file contains the path and format of any image, config or
ephermal disk associated with an instance. When using RAW images and migrating
an instance this file should always be copied or recreated. This avoids the Raw
imagebackend reinspecting the format of these disks when spawning the instance
on the destination host.
By not copying or recreating this disk.info file, a malicious image written to
an instance disk on the source host will cause Nova to reinspect and record a
different format for the disk on the destination. This format then being used
incorrectly when finally spawning the instance on the destination.
Fix processing of libvirt disk.info in non-disk-image cases
In Idfc16f54049aaeab31ac1c1d8d79a129acc9fb87 (upstream) a change was made
that caused non-disk-image backends to fall over because of an
undefined variable because they skipped processing of the disk.info
file. This adds a check for that case to make sure we don't run
that path in the non-disk-image backend case.
libvirt: Decode disk_info before use
The fix for OSSA 2016-007 / CVE-2016-2140 in f302bf04 assumed that
disk_info is always a plain, decoded list. However prior to Liberty
when preforming a live block migration the compute manager populates
disk_info with an encoded JSON string when calling
self.driver.get_instance_disk_info. In the live migration case without
block migration disk_info is None.
As a result we should always decode disk_info when a block migration
is called for to ensure that we can iterate over the disks and rebuild
the disk.info file.
The following change removed the JSON encoding from
get_instance_disk_info and other methods within the libvirt driver for
Liberty.
Reviewed: https:/ /review. fuel-infra. org/18804 ci/fuel- 7.0/2015. 1.0
Submitter: Vitaly Sedelnik <email address hidden>
Branch: openstack-
Commit: ae65990b01462e7 282845ace3ea3ec 6adb02c696
Author: Lee Yarwood <email address hidden>
Date: Wed Apr 13 12:53:24 2016
libvirt: Always copy or recreate disk.info during a migration
The disk.info file contains the path and format of any image, config or
ephermal disk associated with an instance. When using RAW images and migrating
an instance this file should always be copied or recreated. This avoids the Raw
imagebackend reinspecting the format of these disks when spawning the instance
on the destination host.
By not copying or recreating this disk.info file, a malicious image written to
an instance disk on the source host will cause Nova to reinspect and record a
different format for the disk on the destination. This format then being used
incorrectly when finally spawning the instance on the destination.
Fix processing of libvirt disk.info in non-disk-image cases
In Idfc16f54049aae ab31ac1c1d8d79a 129acc9fb87 (upstream) a change was made
that caused non-disk-image backends to fall over because of an
undefined variable because they skipped processing of the disk.info
file. This adds a check for that case to make sure we don't run
that path in the non-disk-image backend case.
libvirt: Decode disk_info before use
The fix for OSSA 2016-007 / CVE-2016-2140 in f302bf04 assumed that get_instance_ disk_info. In the live migration case without
disk_info is always a plain, decoded list. However prior to Liberty
when preforming a live block migration the compute manager populates
disk_info with an encoded JSON string when calling
self.driver.
block migration disk_info is None.
As a result we should always decode disk_info when a block migration
is called for to ensure that we can iterate over the disks and rebuild
the disk.info file.
The following change removed the JSON encoding from disk_info and other methods within the libvirt driver for
get_instance_
Liberty.
libvirt: Remove unnecessary JSON conversions /review. openstack. org/#/c/ 177437/ 6
https:/
SecurityImpact ab31ac1c1d8d79a 129acc9fb87
Closes-bug: #1552683
Change-Id: Idfc16f54049aae