[libvirt] [PATCH 0/8] Hostdev-hybrid patches

[Laine Stump]

On 09/11/2012 04:47 PM, Eric Blake wrote:
> On 09/11/2012 01:07 PM, Laine Stump wrote:
>> * On the guest, these two network devices with matching MAC addresses
>> are put together into a bond interface, with an extra driver that causes
>> the bond to prefer the pci-passthrough device when it is present. So,
>> under normal circumstances *all* traffic goes through the
>> pci-passthrough device.
>>
>> * At migration time, since guests with attached pci-passthrough devices
>> can't be migrated, the pci-passthrough device (which is found by
>> searching the hostdev array for items with the "ephemeral" flag set) is
>> detached. This reduces the bond interface on the guest to only having
>> the virtio-net device, so traffic now passes through that device - it's
>> slower, but connectivity is maintained.
> And if this is the case, it means that 1) the guest must be aware that
> it is virtualized, and 2) can detect when it is being migrated.

Unless I'm misunderstanding, the guest doesn't explicitly know that it's
virtualized or that it's being migrated - the guest OS just knows that
one of its PCI devices has been unplugged, and later that it's being
re-plugged (of course since there's a special driver on the guest, at
least that bit has a pretty good idea that it's in a virtual machine;
but that's no different from the virtio-net guest driver (not to mention
the guest agent)). I'm  guessing that the migration will (should,
anyway) fail if the guest OS fails to detach the device in a timely fashion.


>   The
> ideal virtualization is one in where the guest doesn't have to be aware
> of anything, but the goal of this patch is not ideal guest behavior, so
> much as faster performance by explicitly making virtualization a leaky
> interface where the guest has to cooperate.
>
> Assuming I'm correct, does that have any security implications on the
> host?  Or are we okay even if the guest is malicious, because the worst
> the guest can do is use the slower interface rather than the faster
> pci-passthrough device?


I think the only completely new functionality provided by these patches
is the "ephemeral" flag, which makes it possible for the pci-passthrough
device to be auto-detached to allow migration. So any *new* security
concern would be related to that capability.

Otherwise, I don't see this as any different than defining the two
devices separately, which is already possible with existing libvirt. The
single hostdev-hybrid "two-in-one" device does provide a convenience
factor beyond just shortening the config - the PF to use for the
virtio-net device is automatically derived from the VF that's allocated
for the pci-passthrough device (in my mind that's the one thing that
makes it desirable to have this special device type rather than just
adding the "ephemeral" flag to hostdev and requiring guest
configurations to have two separate device entries. Am I missing
something else?) but it would still be possible to use existing device
types to provide the same virtual hardware to the guest, and the guest
could use that hardware in the same manner.


>> I have other questions beyond that, but either don't understand the code
>> enough yet to verbalize them, or will ask them next to the associated code.
> Seconded :)
>