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>
(cherry picked from commit 441d3eb6)

Currently the scan of the /proc/mounts file used to find cgroup mount
points doesn't take into account that mount points may hidden by other
mount points. For, example in certain Kubernetes environments the
/proc/mounts contains the following lines:

  cgroup /sys/fs/cgroup/net_prio,net_cls cgroup ...
  tmpfs /sys/fs/cgroup tmpfs ...
  cgroup /sys/fs/cgroup/net_cls,net_prio cgroup ...

In this particular environment the first mount point is hidden by the
second one. The correct mount point is the third one, but libvirt will
never process it because it only checks the first mount point for each
controller (net_cls in this case). So libvirt will try to use the first
mount point, which doesn't actually exist, and the complete detection
process will fail.

To avoid that issue this patch changes the virCgroupDetectMountsFromFile
function so that when there are duplicates it takes the information from
the last line in /proc/mounts. This requires removing the previous
explicit condition to skip duplicates, and adding code to free the
memory used by the processing of duplicated lines.

Related-To: https://bugzilla.redhat.com/1468214
Related-To: https://github.com/kubevirt/libvirt/issues/4Signed-off-by: NJuan Hernandez <jhernand@redhat.com>
(cherry picked from commit dacd160d)

Properly error out when the user requests a port from a bus
that does not have a controller present in the domain XML.

https://bugzilla.redhat.com/show_bug.cgi?id=1441589
(cherry picked from commit b003b978)

Found by running valgrind for these tests.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
(cherry picked from commit 9005a64b)

Introduce STRICT_FRAME_LIMIT_CFLAGS that will be used for
production code and RELAXED_FRAME_LIMIT_CFLAGS for tests.

Raising the limit for tests allows building them with clang
with optimizations disabled.

(cherry picked from commit e73889b6)

Like all devices, add the 'id' option for mdevs as well. Patch also
adjusts the test accordingly.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1438431Signed-off-by: NErik Skultety <eskultet@redhat.com>
(cherry picked from commit c3272e5e)

CPU features which change their value from disabled to enabled between
two calls to query-cpu-model-expansion (the first with no extra
properties set and the second with 'migratable' property set to false)
can be marked as enabled and non-migratable in qemuMonitorCPUModelInfo.

Since the code consuming qemuMonitorCPUModelInfo currently ignores the
migratable flag, this change is effectively changing the CPU model
advertised in domain capabilities to contain all features (even those
which block migration). And this matches what we do for QEMU older than
2.9.0, when we detect all CPUID bits ourselves without asking QEMU.

As a result of this change

    <cpu mode='host-model'>
      <feature name='invtsc' policy='require'/>
    </cpu>

will work with all QEMU versions. Such CPU definition would be forbidden
with QEMU >= 2.9.0 without this patch.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

If calling query-cpu-model-expansion on the 'host'/'max' CPU model with
'migratable' property set to false succeeds, we know QEMU is able to
tell us which features would disable migration. Thus we can mark all
enabled features as migratable.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

QEMU is able to tell us whether a CPU feature would block migration or
not. This patch adds support for storing such features in
qemuMonitorCPUModelInfo.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Since commit fcbbb289 we steal the pointer to the storage pool
source name if there was no pool name specified.

Properly duplicate the string to avoid freeing it twice.

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

Pool types that have the VIR_STORAGE_POOL_SOURCE_NAME flag set
allow omitting the <name> element and instead fill out the pool name
from the <source><name> element.

Relax the schema to make <name> optional for these pools.
Expressing that at least one of these is required is out of scope
of the schema.

These tests cover a number of scenarios where we care about
the memory locking limit being set correctly for the guest
to work properly.

This will be used later on in the test suite.

This reverts commit c2e60ad0.

Turns out this check is excessively strict: there are ways
other than <memtune><hard_limit> to raise the memory locking
limit for QEMU processes, one prominent example being
tweaking /etc/security/limits.conf.

Partially-resolves: https://bugzilla.redhat.com/1431793

The mock, as well as the test, is only available on Linux.  So skip
building it everywhere else, especially when it fails on mingw.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

QEMU allows for TSC frequency to be explicitly set to enable migration
with invtsc (migration fails if the destination QEMU cannot set the
exact same frequency used when starting the domain on the source host).

Libvirt already supports setting the TSC frequency in the XML using

    <clock>
      <timer name='tsc' frequency='1234567890'/>
    </clock>

which will be transformed into

    -cpu Model,tsc-frequency=1234567890

QEMU command line.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

The test takes

  x86-cpuid-Something-guest.xml CPU (the CPU libvirt would use for
    host-model on a CPU described by x86_64-cpuid-Something.xml without
    talking to QEMU about what it supports on the host)

and updates it according to CPUID data from QEMU:

  x86_64-cpuid-Something-enabled.xml (reported as "feature-words"
    property of the CPU device)

and

  x86_64-cpuid-Something-disabled.xml (reported as "filtered-features"
    property of the CPU device).

The result is compared to

  x86_64-cpuid-Something-json.xml (the CPU libvirt would use as
    host-model based on the reply from query-cpu-model-expansion).

The comparison is a bit tricky because the *-json.xml CPU contains fewer
disabled features. Only the features which are included in the base CPU
model, but listed as disabled in *.json will be disabled in *-json.xml.
The CPU computed by virCPUUpdateLive from the test data will list all
features present in the host's CPUID data and not enabled in *.json as
disabled. The cpuTestUpdateLiveCompare function checks that the computed
and expected sets of enabled features match.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

All CPU features which QEMU does not know about but libvirt knows them
(currently "cmt" is the only one) are implicitly disabled by QEMU and
should be present in x86_64-cpuid-*-disabled.xml.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Commit v3.1.0-26-gd60012b4 started filtering hle and rtm features from
broken Intel Haswell CPUs. QEMU implemented similar functionality and
thus it doesn't report rtm and hle features as enabled for Core i5-4670T
CPU anymore.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Generated with

    (cd tests/cputestdata; ./cpu-cpuid.py diff x86_64-cpuid-*.json)
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

The new command can be used to generate test data for virCPUUpdateLive.

When "cpu-cpuid.py diff x86-cpuid-Something.json" is run, it reads raw
CPUID data stored in x86-cpuid-Something.xml and CPUID data from QEMU
stored in x86-cpuid-Something.json to produce two more CPUID files:
x86-cpuid-Something-enabled.xml and x86-cpuid-Something-disabled.xml.

- x86-cpuid-Something-enabled.xml will contain CPUID bits present in
    x86-cpuid-Something.json (i.e., enabled by QEMU for the "host" CPU)

- x86-cpuid-Something-disabled.xml will contain all CPUID bits from
    x86-cpuid-Something.xml which are not present in
    x86-cpuid-Something.json (i.e., CPUID bits which the host CPU
    supports, but QEMU does not enable them for the "host" CPU)
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

The new script is going to be more general and the original
functionality can be requested by "cpu-cpuid.py convert".
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Let's make the object local to the parseFeatureWords function which uses
it.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

The public API flags are handled by the cpuBaselineXML wrapper. The
internal cpuBaseline API only needs to know whether it is supposed to
drop non-migratable features.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

cpuBaseline is responsible for computing a baseline CPU while feature
expansion is done by virCPUExpandFeatures. The cpuBaselineXML wrapper
(used by hypervisor drivers to implement virConnectBaselineCPU API)
calls cpuBaseline followed by virCPUExpandFeatures if requested by
VIR_CONNECT_BASELINE_CPU_EXPAND_FEATURES flag.

The features in the three changed test files had to be sorted using
"sort -k 3" because virCPUExpandFeatures returns a sorted list of
features.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

For now, these only cover the unmanaged, i.e. user pre-created devices.
Signed-off-by: NErik Skultety <eskultet@redhat.com>

A mediated device will be identified by a UUID (with 'model' now being
a mandatory <hostdev> attribute to represent the mediated device API) of
the user pre-created mediated device. We also need to make sure that if
user explicitly provides a guest address for a mdev device, the address
type will be matching the device API supported on that specific mediated
device and error out with an incorrect XML message.

The resulting device XML:
<devices>
  <hostdev mode='subsystem' type='mdev' model='vfio-pci'>
    <source>
      <address uuid='c2177883-f1bb-47f0-914d-32a22e3a8804'>
    </source>
  </hostdev>
</devices>
Signed-off-by: NErik Skultety <eskultet@redhat.com>

Instead of generating all of the capabilities, let's test more of our
code by probing sysfs data.  This test needs quite some mocking for
now, but it paves the road for more future enhancements (hugepages
probing, for example).
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

All mocked functions are related to numactl/virNuma and rely only on
virsysfs, so the paths they touch can be nicely controlled.  And
because it is so nicely self-contained NUMA mock, it is named
numamock (instead of naming it after the test that will use it first).

We need top level API mock because some APIs might call libnuma
directly, e.g. virNumaIsAvailable(), virNumaGetMaxNode().
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

Bit more test data, this time with complete info copied, mainly with
cache information, so we can easily add tests for it.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

We'll stop generating the data on the fly, but rather test more of our
APIs.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

There is no "node driver" as there was before, drivers have to do
their own ACL checking anyway, so they all specify their functions and
nodeinfo is basically just extending conf/capablities.  Hence moving
the code to src/conf/ is the right way to go.

Also that way we can de-duplicate some code that is in virsysfs and/or
virhostcpu that got duplicated during the virhostcpu.c split.  And
Some cleanup is done throughout the changes, like adding the vir*
prefix etc.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

There is no reason for it not to be in the utils, all global symbols
under that file already have prefix vir* and there is no reason for it
to be part of DRIVER_SOURCES because that is just a leftover from
older days (pre-driver modules era, I believe).
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

While on that, drop support for kernels from RHEL-5 era (missing
cpu/present file).  Also add some useful functions and export them.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

The functionality these tests partially relied on (scanning the cpu
directory for cpu[0-9]+ subdirectories) is going to be removed, so we
need additional files that are present on all non-medieval systems.
Removing all these tests would be an option but we would lose the
ability to test the topologies.  Even though we just extract number of
sockets/cores/threads from all these directory trees.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

We are not using them at all and the directories are missing bunch of
files already.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>