The default_tls_x509_verify (and related) parameters in qemu.conf
control whether the QEMU TLS servers request & verify certificates
from clients. This works as a simple access control system for
servers by requiring the CA to issue certs to permitted clients.
This use of client certificates is disabled by default, since it
requires extra work to issue client certificates.

Unfortunately the code was using this configuration parameter when
setting up both TLS clients and servers in QEMU. The result was that
TLS clients for character devices and disk devices had verification
turned off, meaning they would ignore errors while validating the
server certificate.

This allows for trivial MITM attacks between client and server,
as any certificate returned by the attacker will be accepted by
the client.

This is assigned CVE-2017-1000256  / LSN-2017-0002
Reviewed-by: NEric Blake <eblake@redhat.com>
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

This adds a rule to require https links for the libvirt, qemu
and kvm websites.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

We stopped autogenerating a TODO file from RFE bugs a long time
ago.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Somewhere around commit 9ff9d9f5 reserving entire PCI slots was
eliminated, as demonstrated by commit 6cc20142.

Reserve the functions required by the implicit devices:
00:01.0 ISA Bridge
00:01.1 IDE Controller
00:01.2 USB Controller (unless USB is disabled)
00:01.3 Bridge

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

xsaveopt is artificially removed from the host to test disabled feature
which is only included in QEMU's version of the CPU model.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

arat is now enabled even if the hardware does not support it.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

xsaves is supported by current QEMU/KVM on this CPU.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

This CPU was incorrectly detected as SandyBridge before because the
number of additional <feature> elements was the same for both
SandyBridge and Westmere CPU models, but SandyBridge is newer (the CPU
signature does not help here because it doesn't match any signature
defined in cpu_map.xml). But since QEMU's version of SandyBridge CPU
model contains xsaveopt which needs to be disabled, Westmere becomes the
best CPU model when translating CPUID data to virCPUDef. Unfortunately,
this doesn't help with translating the data we got from QEMU and the CPU
model is still computed as SandyBridge in this case.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

The unavailable features do not make any difference in this case,
because this is a SandyBridge CPU which has an empty list of unavailable
features.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

When testing cpuDecode for computing guest CPU definition from CPUID
data (the CPU definition reported by domain capabilities), we need to
use CPU models (and their usability blockers) from QEMU if they are
available to cpuDecode in the same way it is actually used in the qemu
driver.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

To make the code reusable by other tests.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

Gather query-cpu-definitions results and use them for testing CPU model
usability blockers in CPUID to virCPUDef translation.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

If the actual result does not match our expectation, the tests would
not correctly show the difference if a CPU feature is disabled in the
expected result and the actual result does not mention it at all. The
test could complain about an unrelated CPU feature or it could even
crash in case the actual result contains no more features to go through.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

Various version of json_reformat use different number of spaces for
indenting. Let's use a simple python reformatter to gain full control
over the formatting for consistent results.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

We will soon need to handle more than two values.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

When decoding CPUID data to virCPUDef we need to be careful about using
a CPU model which cannot be directly used on the current host. Normally,
libvirt would notice the features which prevent the model from being
usable and it would disable them in the computed virCPUDef, but this
won't work in case the definition of the CPU model in QEMU contains more
features than what we have in cpu_map.xml. We need to count with the
usability blockers we got from QEMU and explicitly disable all of them
to make the computed virCPUDef usable.

https://bugzilla.redhat.com/show_bug.cgi?id=1464832Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

This internal API can be used to find a specific CPU model in
virDomainCapsCPUModels list.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

The "preferred" parameter is not used by any caller of cpuDecode
anymore. It's only used internally in cpu_x86 to implement cpuBaseline.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

All APIs which expect a list of CPU models supported by hypervisors were
switched from char **models and int models to just accept a pointer to
virDomainCapsCPUModels object stored in domain capabilities. This avoids
the need to transform virDomainCapsCPUModelsPtr into a NULL-terminated
list of model names and also allows the various cpu driver APIs to
access additional details (such as its usability) about each CPU model.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

query-cpu-definitions QMP command returns a list of unavailable features
which prevent CPU models from being usable on the current host. So far
we only checked whether the list was empty to mark CPU models as
(un)usable. This patch parses all unavailable features for each CPU
model and stores them in virDomainCapsCPUModel as a list of usability
blockers.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

When a hypervisor marks a CPU model as unusable on the current host, it
may also give us a list of features which prevent the model from being
usable. Storing this list in virDomainCapsCPUModel will help the CPU
driver with creating a host-model CPU configuration.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

The API makes a deep copy of a NULL-terminated string list.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

Currently, if parsing of device info fails info->alias is freed.
It doesn't make much sense to leave the rest of the struct
behind.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

There's one 'return' in the middle of the function body. It's
very easy to miss and so it makes adding new code harder. Also
the function doesn't follow our style 100%.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

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

In 0d3d020b I've added capability to accept MAC addresses
for the API too. However, the implementation was faulty. It needs
to lookup the corresponding interface in the domain definition
and pass the ifname instead of MAC address.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

Commit id '8708ca01' added a check to determine whether the NIC had
Switchdev capabilities; however, in doing so inadvertently would cause
network devices without a PCI device to not be added to the node device
database. Thus, network devices having a "computer" as a parent, such
as "net_lo*", "net_virbr*", "net_tun*", "net_vnet*", etc. were not added.

Alter the check to not even check for Switchdev bits if no PCI device found.

The command tries to match interface in domain definition by MAC
address or interface name. However, since it's possible to
configure two interfaces with the same MAC address, it may
happen that the XPath returns two or more nodes. We should check
for that.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

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

The other APIs accept both, ifname and MAC address. There's no
reason virDomainInterfaceStats can't do the same.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

Every caller reports the error themselves. Might as well move it
into the function and thus unify it.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

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

The current implementation reads the stats from the host.
However, this doesn't work for all types of interfaces as not all
of them have a representation in the host. For instance,
interface type='user' doesn't.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

It only returns 0 or 1 anyway, let's be realistic
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Let's use the RWObjectLockable for the various list lock mgmt.
Only time need Write lock will be for Add/Remove logic.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Let's use the ObjectRWLockable for the various list lock mgmt.
Only time need Write lock will be for Add/Remove logic.

Let's use the RWObjectLockable for the various list lock mgmt.
Only time need Write lock will be for Add, Remove, and Prune logic.

Need to free @groups in the parent on success similar to other
APIs (virFile*) which use virGetGroupList and virFork.

Reported by Coverity.