Peter Krempa [Tue, 2 Feb 2021 16:04:30 +0000 (17:04 +0100)]
qemuBuildRBDSecinfoURI: Use virSecureEraseString instead of VIR_AUTODISPOSE_STR
In this instance attempting to be correct is really pointless since the
secret is formatted into another string which is not erased securely and
then put on the commandline.
Keep the secure handling for correctness.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Peter Krempa [Mon, 1 Feb 2021 13:16:54 +0000 (14:16 +0100)]
tests: viralloc: Remove testDispose case
The VIR_DISPOSE* APIs will be phased out. Additionally the test isn't
really doing useful work in ensuring that the values are indeed cleared
thus there's no point in keeping it around.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
The code pretends that it cares about clearing the secret values, but
passes the secret value to a realloc, which may copy the value somewhere
else and doesn't sanitize the original location when it does so.
Since we want to construct a string from the value, let's copy it to a
new piece of memory which has the space for the 'NUL' byte ourselves, to
prevent a random realloc keeping the data around.
While at it, use virSecureErase instead of VIR_DISPOSE_N since it's
being phased out.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Peter Krempa [Mon, 1 Feb 2021 13:01:57 +0000 (14:01 +0100)]
virsh: cmdSecretSetValue: Rework handling of the secret value
Use a single buffer for the secret to make it easier to follow it's
lifecycle. For base64 decoding use a local temporary buffer which will
be cleared right away.
This also uses virSecureErase for clearing the bufer instead of
VIR_DISPOSE_N which is being phased out.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Peter Krempa [Mon, 1 Feb 2021 11:12:42 +0000 (12:12 +0100)]
libxlMakeDomBuildInfo: Don't use VIR_DISPOSE_N for USB device list
The list isn't secret which would need being disposed of. Just expand
the array and return failure when adding the NULL terminator similarly
to how we expand the list for adding devices in a loop.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Peter Krempa [Mon, 1 Feb 2021 11:08:13 +0000 (12:08 +0100)]
hypervFreeInvokeParams: Don't use VIR_DISPOSE_N for freeing 'params'
The struct doesn't contain any secrets to clear before freeing and even
if it did VIR_DISPOSE_N wouldn't help as the struct contains only
pointers thus the actual memory pointing to isn't sanitized.
Just free the params array pointer and then the struct itself.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Tim Wiederhake [Mon, 1 Feb 2021 12:42:06 +0000 (13:42 +0100)]
vircryptotest: Directly assign string to avoid memcpy
Found by clang-tidy's "bugprone-not-null-terminated-result" check.
clang-tidy's finding is a false positive in this case, as the
memset call guarantees null termination. The assignment can be
simplified though, and this happens to silence the warning.
Signed-off-by: Tim Wiederhake <twiederh@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Tim Wiederhake [Mon, 1 Feb 2021 12:42:02 +0000 (13:42 +0100)]
Replace bzero() with memset()
This was found by clang-tidy's
"clang-analyzer-security.insecureAPI.bzero" check.
bzero is marked as deprecated ("LEGACY") in POSIX.1-2001 and
removed in POSIX.1-2008.
Besides its deprecation, bzero can be unsafe to use under certain
circumstances, e.g. when used to zero-out memory containing secrects.
These calls can be optimized away by the compiler, if it concludes no
further access happens to the memory, thus leaving the secrets still
in memory. Hence its classification as "insecureAPI".
Signed-off-by: Tim Wiederhake <twiederh@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Matt Coleman [Tue, 2 Feb 2021 00:48:36 +0000 (19:48 -0500)]
hyperv: XML parsing of serial ports
Co-authored-by: Sri Ramanujam <sramanujam@datto.com> Signed-off-by: Matt Coleman <matt@datto.com> Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Michal Privoznik [Wed, 25 Nov 2020 09:40:50 +0000 (10:40 +0100)]
virsh: Simplify @flags handing in cmdSetmem() and cmdSetmaxmem()
What code tries to achieve is that if no flags were provided to
either 'setmem' or 'setmaxmem' commands then the old (no flags)
API is called to be able to communicate with older daemons.
Well, the code can be simplified a bit.
Note that with this change the old no flag version of APIs is
used more often. Previously if --current argument was given it
resulted in *Flags() version to be called even though it is not
necessary - VIR_DOMAIN_AFFECT_CURRENT is implied.
Therefore, this change in fact allows virsh to talk with broader
set of daemons. No other user visible changes were made.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Laine Stump [Sat, 30 Jan 2021 19:05:50 +0000 (14:05 -0500)]
conf: replace VIR_FREE() with g_free() in vir*Free() functions
This patch takes on one set of examples of unnecessary use of
VIR_FREE() when g_free() is adequate - it modifies only vir*Free()
functions within the conf directory that take a single pointer and
free the object pointed to by that argument before returning. The
modification is to replace VIR_FREE() with g_free() for the object
itself *and* for all subordinate chunks of memory pointed to by that
object.
(NB: there are other functions that VIR_FREE subordinate memory of
objects that end up being freed before return (also sometimes with
VIR_FREE); I am purposefully ignoring those to reduce scope and focus
on a sub class where the pointlessness is obvious.)
Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Laine Stump [Fri, 29 Jan 2021 05:12:28 +0000 (00:12 -0500)]
util: rename virStorageEncryptionInfoDefFree()
usually a function call vir*Free() will take a single pointer to an
object as its argument, and will then free all resources associated
with that object, including the object
itself. virStorageEnctyptionInfoDefFree() doesn't do that - it frees
all the subordinate resources of the ojbect, but doesn't free the
object itself; usually a function like that is called
vir*Clear(). Let's rename this function to not be misleading.
Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Laine Stump [Fri, 29 Jan 2021 04:39:33 +0000 (23:39 -0500)]
conf: eliminate pointless setting of interface model
There is no point in setting the interface model to unknown during
virDomainNetDefFree(), since we are about to free the object anyway
(and the model isn't used anywhere in the rest of the function).
Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Laine Stump [Sat, 30 Jan 2021 19:02:28 +0000 (14:02 -0500)]
conf: fix arg to virDomainPCIAddressSetExtensionFree()
This function clears out and frees a virDomainZPCIAddressIds object,
so that's that's what it should take as its argument, *not* the
pointer to a parent object that contains the object we want to free.
Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Laine Stump [Tue, 26 Jan 2021 05:31:16 +0000 (00:31 -0500)]
hostdevmgr: remove unneeded oldStateDir
Back in commit 2c71d3826, which appeared in libvirt-1.2.3 in April
2014, the location used to store saved MAC addresses and vlan tags of
SRIOV VFs was changed from /var/run/libvirt/qemu to
/var/run/libvirt/hostdevmgr. For backward compatibility the code was
made to continue looking in the old location for the files when it
didn't find them in the new location.
It's now been 6 years, and even if there was somebody still running
libvirt-1.2.3 on their system, that system would now be out of support
for libvirt, so there would be no way for them to upgrade to a new
libvirt that no longer looks in "oldStateDir" for the files. So
let's no longer look in "oldStateDir" for the files!
Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Laine Stump [Tue, 26 Jan 2021 04:54:57 +0000 (23:54 -0500)]
log error if virConnectCacheOnceInit() fails
virGetConnectNetwork() calls
virGetConnectGeneric(), which calls
virConnecCacheInitialize(), which is actually a call (only once) to
virConnectCacheOnceInit() which calls
virThreadLocalInit() several times, which calls
pthread_key_create()
If pthread_key_create() fails, it (of course) doesn't log an error
(because it's not a part of libvirt), nor does any other function on
the call chain all the way up to virGetConnectNetwork(). But none of
the callers of virGetConnectNetwork() log an error either, so it is
possible that an API could fail due to virGetConnectNetwork() failing,
but would only log "an error was encountered, but the cause is
unknown. Deal with it." (paraphrasing).
(In all likelyhood, virConnectCacheOnceInit() is going to be called at
some earlier time, and almost certainly pthread_key_create() will
never fail (and if it does, the user will have *much* bigger problems
than an obtuse error message from libvirt)).
Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
virfile: workaround for when posix_fallocate() is not supported by FS
posix_fallocate() might be not supported by a filesystem, for example,
it's not supported by ZFS. In that case it fails with
return code 22 (EINVAL), and thus safezero_posix_fallocate() returns -1.
As safezero_posix_fallocate() is the first function tried by safezero()
and it tries other functions only when it returns -2, it fails
immediately without falling back to other methods, such as
safezero_slow().
Fix that by returning -2 if posix_fallocate() returns EINVAL, to give
safezero() a chance to try other functions.
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Thomas Huth [Fri, 29 Jan 2021 14:37:26 +0000 (15:37 +0100)]
docs: Clarify the documentation of the <css> elements
The channel subsystem elements describe a channel in the I/O subsystem
of a s390x machine, and not a normal device (like a disk or network card).
Reword the documentation here to make it this a little bit clearer.
Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=1898074 Reviewed-by: Boris Fiuczynski <fiuczy@linux.ibm.com> Signed-off-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Cornelia Huck <cohuck@redhat.com>
Laine Stump [Sun, 17 Jan 2021 19:27:20 +0000 (14:27 -0500)]
rpm: disable netcf for the interface driver in rpm build on new targets
libvirt.spec currently adds a hardcoded -Dnetcf=enabled to the meson
commandline, so just setting the default in the meson.build file won't
have any effect for rpm builds - it will be overridden.
This patch changes the meson commandline in the spec file from
hardcoded -Dnetcf=enabled to %{arg_netcf}, which is itself set
according to the value of %{with_netcf}; and *that* is normally set
according to the distro release of the build target (1 for Fedora >=
34 and RHEL >= 9, 0 otherwise), but can be manually overridden by
adding "-without netcf" to the rpmbuild commandline.
Along with being used to determine what arg to pass to meson,
%{with_netcf} is also checked when deciding on whether or not to add
netcf build time / install time dependencies ("Requires: netcf-libs"
and "BuildRequires: netcf-devel")
Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Neal Gompa <ngompa13@gmail.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Laine Stump [Thu, 21 Jan 2021 21:01:06 +0000 (16:01 -0500)]
build: support explicitly disabling netcf
placing "-Dnetcf=disabled" on the meson commandline was ignored,
meaning that even with that option the build would get WITH_NETCF if
the netcf-devel package was found - the only way to disable it was to
uninstall netcf-devel.
This patch adds the small bit of logic to check the netcf meson
commandline option (in addition to whether netcf-devel is installed)
before defining WITH_NETCF.
Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Neal Gompa <ngompa13@gmail.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The current virPCIDeviceNew() signature, receiving 4 uints in sequence
(domain, bus, slot, function), is not neat.
We already have a way to represent a PCI address in virPCIDeviceAddress
that is used in the code. Aside from the test files, most of
virPCIDeviceNew() callers have access to a virPCIDeviceAddress reference,
but then we need to retrieve the 4 required uints (addr.domain, addr.bus,
addr.slot, addr.function) to satisfy virPCIDeviceNew(). The result is
that we have extra verbosity/boilerplate to retrieve an information that
is already available in virPCIDeviceAddress.
A better way is presented by virNVMEDeviceNew(), where the caller just
supplies a virPCIDeviceAddress pointer and the function handles the
details internally.
This patch changes virPCIDeviceNew() to receive a virPCIDeviceAddress
pointer instead of 4 uints.
Reviewed-by: Laine Stump <laine@redhat.com> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
qemu, lxc: move NodeDeviceGetPCIInfo() function to domain_driver.c
libxlNodeDeviceGetPCIInfo() and qemuNodeDeviceGetPCIInfo() are equal.
Let's move the logic to a new virDomainDriverNodeDeviceGetPCIInfo()
info to be used by libxl_driver.c and qemu_driver.c.
Reviewed-by: Laine Stump <laine@redhat.com> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Boris Fiuczynski [Fri, 29 Jan 2021 11:39:22 +0000 (12:39 +0100)]
conf: rename virDomainCheckVirtioOptions
Rename virDomainCheckVirtioOptions into
virDomainCheckVirtioOptionsAreAbsent since it checks if all
virtio options are absent. The old name was very misleading.
Signed-off-by: Boris Fiuczynski <fiuczy@linux.ibm.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
projects / libvirt.git / log