CVE-2016-5008

Setting an empty graphics password is documented as a way to disable
VNC/SPICE access, but QEMU does not always behaves like that. VNC would
happily accept the empty password. Let's enforce the behavior by setting
password expiration to "now".

https://bugzilla.redhat.com/show_bug.cgi?id=1180092Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

When support for <interface type='ethernet'> was added in commit
9a4b705f back in 2010, it erroneously looked at <source dev='blah'/>
for a user-specified guest-side interface name. This was never
documented though. (that attribute already existed at the time in the
data.ethernet union member of virDomainNetDef, but apparently had no
practical use - it was only used as a storage place for a NetDef's
bridge name during qemuDomainXMLToNative(), but even then that was
never used for anything).

When support for similar guest-side device naming was added to the lxc
driver several years later, it was put in a new subelement <guest
dev='blah'/>.

In the intervening years, since there was no validation that
ethernet.dev was NULL in the other drivers that didn't actually use
it, innocent souls who were adding other features assuming they needed
to account for non-NULL ethernet.dev when really they didn't, so
little bits of the usual pointless cargo-cult code showed up.

This patch not only switches the openvz driver to use the documented
<guest dev='blah'/> notation for naming the guest-side device (just in
case anyone is still using the openvz driver), and logs an error if
anyone tries to set <source dev='blah'/> for a type='ethernet'
interface, it also removes the cargo-cult uses of ethernet.dev and
<source dev='blah'/>, and eliminates if from the RNG and from
virDomainNetDef.

NB: I decided on this course of action after mentioning the
inconsistency here:

  https://www.redhat.com/archives/libvir-list/2016-May/msg02038.html

and getting encouragement do eliminate it in a later IRC discussion
with danpb.

Commit 409de00e changed the logic to only match PCI devices
while moving this before Remove*HostDevice calls.

https://bugzilla.redhat.com/show_bug.cgi?id=1342874

qemuDomainDiskBlockJobIsActive already checks if a disk has a
blockjob, and if so, raises an error

Refactor the error paths for attaching char device (it's about to be
more complicated).
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

Since commit 71408079, qemu agent
channel cannot be plugged in because we won't generate its path
automatically.  Let's not only fix that, but also add tests for it so
next time it's checked for.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1322210Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

Hand-entering indexes for 20 PCI controllers is not as tedious as
manually determining and entering their PCI addresses, but it's still
annoying, and the algorithm for determining the proper index is
incredibly simple (in all cases except one) - just pick the lowest
unused index.

The one exception is USB2 controllers because multiple controllers in
the same group have the same index. For these we look to see if 1) the
most recently added USB controller is also a USB2 controller, and 2)
the group *that* controller belongs to doesn't yet have a controller
of the exact model we're just now adding - if both are true, the new
controller gets the same index, but in all other cases we just assign
the lowest unused index.

With this patch in place and combined with the automatic PCI address
assignment, we can define a PCIe switch with several ports like this:

  <controller type='pci' model='pcie-root-port'/>
  <controller type='pci' model='pcie-switch-upstream-port'/>
  <controller type='pci' model='pcie-switch-downstream-port'/>
  <controller type='pci' model='pcie-switch-downstream-port'/>
  <controller type='pci' model='pcie-switch-downstream-port'/>
  <controller type='pci' model='pcie-switch-downstream-port'/>
  <controller type='pci' model='pcie-switch-downstream-port'/>
  ...

These will each get a unique index, and PCI addresses that connect
them together appropriately with no pesky numbers required.

Signed-off-by: NShivaprasad G Bhat <sbhat@linux.vnet.ibm.com>

Use the detected tray presence flag to trigger the tray waiting code
only if the given storage device in qemu reports to have a tray.

This is necessary as the floppy device lost it's tray as of qemu commit:

commit abb3e55b5b718d6392441f56ba0729a62105ac56
Author: Max Reitz <mreitz@redhat.com>
Date:   Fri Jan 29 20:49:12 2016 +0100

    Revert "hw/block/fdc: Implement tray status"

Commit 1fad65d4 used a really big hammer
and overwrote the error message that might be reported by qemu if the
tray is locked. Fix it by reporting the error only if no error is
currently set.

Error after commit mentioned above:
error: internal error: timed out waiting for disk tray status update

New error:
error: internal error: unable to execute QEMU command 'eject': Tray of
device 'drive-ide0-0-0' is not open

The code grew rather convoluted. Extract it to a separate function.

Move it to a more sane place since it's refreshing data about disks.

We have been always setting the capability on if qemu has
QEMU_CAPS_DEVICE.

Remove more checks that are no longer necessary.

This reverts commit 1ccc7fbf.

We cannot check ports if autoport is set because we set ports to 0 while
parsing device XML.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1336134Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

The INPLACE variants of the VIR_APPEND macros cannot fail and they are
inherently quiet.

It was just a useless wrapper around VIR_APPEND_ELEMENT*.

If we exceed the timeout waiting for the tray status to change,
we don't report an error. Fix it

QEMU_CAPS_DEVICE is always set nowadays, so we can drop the
non-DEVICE code paths

We cannot change ports for running domain and we should error out if
autoport is enabled.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

Add the data structure and infrastructure to support an initialization
vector (IV) secrets. The IV secret generation will need to have access
to the domain private master key, so let's make sure the prepare disk
and hostdev functions can accept that now.

Anywhere that needs to make a decision over which secret type to use
in order to fill in or use the IV secret has a switch added.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

We had both and the only difference was that the latter also included
information about multifunction setting.  The problem with that was that
we couldn't use functions made for only one of the structs (e.g.
parsing).  To consolidate those two structs, use the one in virpci.h,
include that in domain_conf.h and add the multifunction member in it.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

If we failed to build the aliases or attach the chardev, then the props
would be leaked - fix that.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Adjust error path logic to make it clearer how to undo the failed add.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Adjust error path logic to make it clearer how to undo the failed add.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Adjust error path logic to make it clearer how to undo the failed add.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Similar to the qemuDomainSecretDiskPrepare, generate the secret
for the Hostdev's prior to call qemuProcessLaunch which calls
qemuBuildCommandLine. Additionally, since the secret is not longer
added as part of building the command, the hotplug code will need
to make the call to add the secret in the hostdevPriv.

Since this then is the last requirement to pass a virConnectPtr
to qemuBuildCommandLine, we now can remove that as part of these
changes. That removal has cascading effects through various callers.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Rather than needing to pass the conn parameter to various command
line building API's, add qemuDomainSecretPrepare just prior to the
qemuProcessLaunch which calls qemuBuilCommandLine. The function
must be called after qemuProcessPrepareHost since it's expected
to eventually need the domain masterKey generated during the prepare
host call. Additionally, future patches may require device aliases
(assigned during the prepare domain call) in order to associate
the secret objects.

The qemuDomainSecretDestroy is called after the qemuProcessLaunch
finishes in order to clear and free memory used by the secrets
that were recently prepared, so they are not kept around in memory
too long.

Placing the setup here is beneficial for future patches which will
need the domain masterKey in order to generate an encrypted secret
along with an initialization vector to be saved and passed (since
the masterKey shouldn't be passed around).

Finally, since the secret is not added during command line build,
the hotplug code will need to get the secret into the private disk data.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>