[PATCH 06/11] hyperv: attach virtual disks when defining domains
Matt Coleman
mcoleman at datto.com
Fri Jan 8 22:55:55 UTC 2021
> On Nov 26, 2020, at 9:48 AM, Daniel P. Berrangé <berrange at redhat.com> wrote:
>
> On Tue, Nov 24, 2020 at 02:48:35PM -0500, Matt Coleman wrote:
>> + g_autofree char *addressString = g_strdup_printf("%u", disk->info.addr.drive.unit);
>
> Validate disk->info.type == DRIVE before accessing this field otherwise
> the union contents is undefined.
>> + if (hypervSetEmbeddedProperty(volumeResource, "ResourceType", resourceType) < 0)
>> + return -1;
>> +
>> + if (hypervSetEmbeddedProperty(volumeResource, "ResourceSubType",
>> + "Microsoft:Hyper-V:Virtual Hard Disk") < 0)
>> + return -1;
>
> The disk->device can be disk, or cdrom or floppy. So if you're hadcoding disk, then
> validate disk->device matches.
The logic in hypervDomainAttachStorageVolume() ensures that it only
calls hypervDomainAttachVirtualDisk() if disk->device is equal to
VIR_DOMAIN_DISK_DEVICE_DISK.
Should I add another check inside hypervDomainAttachVirtualDisk() or is
it acceptable to validate within hypervDomainAttachStorageVolume() as
long as no other functions call hypervDomainAttachVirtualDisk()?
If this is acceptable, I could also validate disk->info.type inside
hypervDomainAttachStorageVolume(), which would cover the other two
critiques.
>> + VIR_DEBUG("Now attaching disk image '%s' with address %d to bus %d of type %d",
>> + disk->src->path, disk->info.addr.drive.unit, disk->info.addr.drive.controller, disk->bus);
>
> Don't access the disk->info.addr until its type is validated
More information about the libvir-list
mailing list