Laine Stump [Thu, 4 Feb 2021 02:12:21 +0000 (21:12 -0500)]
rpc: eliminate static function virNetLibsshSessionAuthMethodsFree()
This function is only called from one place, and has, well... not a
*misleading* name, but it doesn't fit the standard frame of functions
that end in "Free" (it doesn't actually free the object pointed to by
its argument, but frees *some parts* of the content of the object).
Rather than try to think up an appropriate name, let's just move the
meat of this function into its one and only caller,
virNetLibsshSessionDispose(), which will allow us to convert its
VIR_FREEs into g_free in a future patch.
Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Laine Stump [Tue, 2 Feb 2021 06:11:30 +0000 (01:11 -0500)]
conf: simplify virDomainCapsDispose()
virDomainCapsDispose() was the only caller of
virDomainCapsStringValuesFree(), which 1) didn't actually free the
object it was called with, but only cleared it, making it less
mechanical to convert from VIR_FREE to g_free (since it's not
immediately obvious from looking at virDomainCapsStringValuesFree()
that the pointers being cleared will never again be used).
We could have renamed the function to virDomainCapsStringValuesClear()
to side-step the confusion of what the function actually does, but
that would just make the upcoming switch from VIR_FREE to g_free
require more thought. But since there is only a single caller to the
function, and it is a vir*Dispose() function (indicating that the
object containing the virDomainCapsStringValues is going to be freed
immediately after the function finishes), and thus VIR_FREE() *could*
be safely replaced by g_free()), we instead just move the contents of
virDomainCapsStringValuesFree() into virDomainCapsDispose() (and
*that* function will be trivially converted in an upcoming
"mechanical" patch).
Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Laine Stump [Thu, 4 Feb 2021 02:51:04 +0000 (21:51 -0500)]
rpc: rename virNetSessionAuthMethodsFree to virNetSessionAuthMethodsClear
This is another *Free() function that doesn't free the object it is
passed. Instead it frees and clears some parts of the object.
In this case, the function is actually called from two places, and one
of them (virNetSSHSessionAuthReset) appears to be assuming that the
pointers actually *will* be cleared. So the proper thing to do here
(?) is to rename the function to virNetSSHSesionAuthMethodsClear().
(NB: virNetSSHSessionAuthReset is seemingly never called from
anywhere. Is this one of those functions that actually *is* called by
some strange MACRO invocation? Or it is truly one of those
"written-but-never-used" functions that can be deleted? (if the latter
is the case, then I would rather move the contents of
virNetSessionAuthMethodsFree() into its only other caller,
virNetSSHSessionDispose(), so that the VIR_FREEs could be replaced
with g_free.)
Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Laine Stump [Thu, 4 Feb 2021 02:07:20 +0000 (21:07 -0500)]
qemu: replace VIR_FREE with g_free in qemuFirmware*FreeContent()
These functions are all only called as a part of qemuFirmwareFree(),
which frees the qemuFirmware object before return, so we can be sure
none of the pointers is referenced after freeing (and thus there is no
need to clear any of them).
Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Laine Stump [Wed, 3 Feb 2021 21:57:57 +0000 (16:57 -0500)]
qemu: pass pointers instead of copying objects for qemuFirmware*FreeContent()
These functions all cooperate to free memory pointed to by a single
object that contains (doesn't *point to*, but actually contains)
several sub-objects. They were written to send copies of these
sub-objects to subordinate functions, rather than just sending
pointers to the sub-objects.
Let's change these functions to just send pointers to the objects
they're cleaning out rather than all the wasteful and pointless
copying.
Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Laine Stump [Wed, 3 Feb 2021 21:07:59 +0000 (16:07 -0500)]
qemu: rename virFirmware*Free() functions to have more accurate names
Several functions had the names virFirmware[something]Free(), but they
aren't taking a pointer to some object and freeing it. Instead, they
are making a copy of the content of an entire object, then Freeing the
objects pointed to by that content.
As a first step in a too-complicated cleanup just to eliminate a few
occurrences of VIR_FREE(), this patch renames those functions to more
accurately reflect what they do - they Free the *Content* of their
arguments.
Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Laine Stump [Thu, 4 Feb 2021 02:38:59 +0000 (21:38 -0500)]
util: rename two *Free() functions while changing VIR_FREE to g_free
dhcpHostFree() and addnHostFree() don't follow the normal pattern of
*Free functions in the rest of libvirt code - they are actually more
similar to the *Dispose() functions, in that they free all subordinate
objects, but not the object pointed to by the argument
itself. However, the arguments aren't virObjects, so it wouldn't be
proper to name them *Dispose() either.
They *currently* behave similar to a *Clear() function, in that they
free all the subordinate objects and nullify the pointers of those
objects. HOWEVER, we don't actually need or want that behavior - the
two functions in question are only called as part of a higher level
*Free() function, and the pointers are not referenced in any way
between the time they are freed and when the parent object is freed.
So, since the current name isn't correct, nor is *Dispose(), and we
want to change the behavior in such a way that *Clear() also wouldn't
be correct, lets name the functions *FreeContent(), which is an
accurate description of what the functions do, and what we *want* them
to do.
And since it's such a small patch, we can go ahead and change that
behavior - replacing the VIR_FREEs with g_free.
Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
We should not mock stat64() when building on Apple Silicon,
because the declaration is not present in the header file.
Detect this situation and handle it gracefully.
https://gitlab.com/libvirt/libvirt/-/issues/121
Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
On macOS, most of the symbols and declarations that we look at
to determine which versions of stat() we need to mock are not
present; on the other hand, there are some specific wrinkles
that are introduced with Apple Silicon which we will need to
take care of.
To avoid making the logic even more of an opaque mess than it
currently is, move the macOS part to a separate branch.
This commit is better viewed with 'git show -w'.
Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Pavel Hrdina [Wed, 3 Feb 2021 15:28:40 +0000 (16:28 +0100)]
qemu_driver: increase recorded counter for disk block stats
Commit <318d807a0bd3372b634d1952b559c5c627ccfa5b> added a fix to skip
most of the block stat code to not log error message for missing storage
sources but forgot to increase the recordnr counter.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
vircgroup: Don't leak @parent in virCgroupEnableMissingControllers()
A memory leak was identified in
virCgroupEnableMissingControllers():
==11680== at 0x483EAE5: calloc (vg_replace_malloc.c:760)
==11680== by 0x4E51780: g_malloc0 (in /usr/lib64/libglib-2.0.so.0.6701.0)
==11680== by 0x4908618: virCgroupNew (vircgroup.c:701)
==11680== by 0x49096F4: virCgroupEnableMissingControllers (vircgroup.c:1146)
==11680== by 0x4909B17: virCgroupNewMachineSystemd (vircgroup.c:1228)
==11680== by 0x4909E94: virCgroupNewMachine (vircgroup.c:1313)
==11680== by 0x1694FDBC: qemuInitCgroup (qemu_cgroup.c:946)
==11680== by 0x1695046B: qemuSetupCgroup (qemu_cgroup.c:1083)
==11680== by 0x16A60126: qemuProcessLaunch (qemu_process.c:7077)
==11680== by 0x16A61504: qemuProcessStart (qemu_process.c:7384)
==11680== by 0x169B84C2: qemuDomainObjStart (qemu_driver.c:6590)
==11680== by 0x169B8776: qemuDomainCreateWithFlags (qemu_driver.c:6641)
What happens is that new virCgroup is created and stored into
@parent. Then, if @tokens is not empty the for() loop is entered
into where another virCgroup is created and @parent is replaced
with this new virCgroup. But nothing freed the old @parent.
Fixes: 77291414c7a8745cf4d2b06d3c38d269cfbcfe32 Reported-by: Andrea Bolognani <abologna@redhat.com> Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Laine Stump [Tue, 2 Feb 2021 17:51:48 +0000 (12:51 -0500)]
build: fix specfile logic for disabling netcf
I *thought* I had tested all the combinations of manually setting
--without netcf, different versions of Fedora, etc, but apparently
not.
The check in libvirt.spec.in to see if the target was an older Fedora
or older RHEL would alway resolve to true, because, e.g., if {?fedora}
is undefined, then "0%{?fedora} < 34" is "0 < 34", which is always
true. Since both {?fedora} and {?rhel} are never defined at the same
time, the result of the entire expression is always true.
Fix this by qualifying each subexpression.
Fixes: 35d5b26aa433bd33f4b33be3dbb67313357f97f9 Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Peter Krempa [Wed, 3 Feb 2021 12:43:28 +0000 (13:43 +0100)]
viralloc: Remove VIR_ALLOC_VAR
The use case VIR_ALLOC_VAR deals with is very unlikely. We had just 2
legitimate uses, which were reimplemented locally using g_malloc0 and
sizeof instead as they used a static number of members of the trailing
array.
Remove VIR_ALLOC_VAR since in most cases the direct implementation is
shorter and clearer and there are no users of it currently.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
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>