desc length should be always less than VIR_STORAGE_MAX_HEADER.
If len = VIR_STORAGE_MAX_HEADER, desc may be out of bounds.
Fixes: 296032bfb2 ("util: extract storage file probe code into virtstoragefileprobe.c")
Signed-off-by: Anastasia Belova <abelova@astralinux.ru>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The changes to the output files are the exact opposite of
those from commit 22207713cf: this is proof that the fix is
working as intended, and that existing domains will keep using
raw firmware images regardless of whether or not qcow2 images
are available on the system and have higher priority.
New domains will keep picking whatever firmware is considered
the preferred one according to the order of descriptors, as
evidenced by the fact that the recently introduced
firmware-auto-efi-abi-update-aarch64 test case is unaffected.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
The input is identical to that of the existing
firmware-auto-efi-aarch64 test, but in this case we want to
cover the scenario in which that input is used to define a new
domain rather than loading the definition of an existing domain
from disk.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
There are couple of g_dbus_*() functions we provide an
alternative implementation for in our virgdbusmock.c. However,
these functions are declared in gio/gdbusconnection.h as:
GIO_AVAILABLE_IN_ALL
GDBusConnection *g_bus_get_sync (GBusType bus_type,
GCancellable *cancellable,
GError **error);
where GIO_AVAILABLE_IN_ALL is declared as (in
/gio/gio-visibility.h):
#if (defined(_WIN32) || defined(__CYGWIN__)) && !defined(GIO_STATIC_COMPILATION)
# define _GIO_EXPORT __declspec(dllexport)
# define _GIO_IMPORT __declspec(dllimport)
#elif __GNUC__ >= 4
# define _GIO_EXPORT __attribute__((visibility("default")))
# define _GIO_IMPORT
#else
# define _GIO_EXPORT
# define _GIO_IMPORT
#endif
#ifdef GIO_COMPILATION
# define _GIO_API _GIO_EXPORT
#else
# define _GIO_API _GIO_IMPORT
#endif
#define _GIO_EXTERN _GIO_API extern
#define GIO_AVAILABLE_IN_ALL _GIO_EXTERN
Now, on mingw the functions we mock are declared with dllimport
attribute which makes the compiler unhappy:
../tests/virgdbusmock.c:25:24: error: 'g_bus_get_sync'
redeclared without dllimport attribute: previous dllimport
ignored [-Werror=attributes]
The solution is to do what glib does when it compiles the gio
module: set GIO_COMPILATION macro which in turn annotates the
function with dllexport attribute.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Updated by "Update PO files to match POT (msgmerge)" hook in Weblate.
Translation: libvirt/libvirt
Translate-URL: https://translate.fedoraproject.org/projects/libvirt/libvirt/
Co-authored-by: Weblate <noreply@weblate.org>
Signed-off-by: Fedora Weblate Translation <i18n@lists.fedoraproject.org>
This reverts commit 1f76b5365e.
There were two issues with this commit. First is the missing propagation
of CFLAGS into the build environment and second is the fact that this is
not enough to disable the check for -fsemantic-interposition. The
proper fix would require setting MESON_OPTS or similar and also add the
propagation of such variable into the cirrus builds etc., but at this
point I burned so much time on this trivial piece of rubbish that I
think it's easier to just wait for macos to gain a newer clang =D
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
While it's true that the default username is:
administrator@${SSO-Domain}
in majority of cases the ${SSO-Domain} is "vsphere.local". But
our code (and what virsh displays then) says it's just
"administrator".
This is wrong also from a different POV: the username must
contain the suffix no matter what and our default suggests
otherwise.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2181234
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
In vir-host-validate we do two checks related to IOMMU:
1) hardware support, and
2) kernel support.
While users are usually interested in the latter, the former also
makes sense. And for the former (hardware support) we have this
huge if-else block for nearly every architecture, except ARM.
Now, IOMMU is called SMMU in ARM world, and while there's
certainly a definitive way of detecting SMMU support (e.g. via
dumping some registers in asm), we can work around this - just
like we do for Intel and AMD - and check for an ACPI table
presence.
In ARM world, there's I/O Remapping Table (IORT) which describes
SMMU capabilities on given host and is exposed in sysfs
(regardless of arm_smmu module).
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2178885
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
This updates to FreeBSD 12.4 which has clang that supports
-fsemantic-interposition, plus of course updates the system.
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
There are some CLang versions that do not support
-fsemantic-interposition. If that's the case, the code is
optimized so much that our mocking no longer works.
Therefore, disable tests and produce a warning.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
The '15.3' version is EOL now:
https://get.opensuse.org/leap/15.3/
Also switch the 'codestyle' job to the appropriate container image.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
As a precursor to dropping the EOL OpenSUSE 15.3 job add first the
definitions for the replacement version.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Currently translated at 22.5% (2349 of 10416 strings)
Translation: libvirt/libvirt
Translate-URL: https://translate.fedoraproject.org/projects/libvirt/libvirt/fi/
Co-authored-by: Jan Kuparinen <copper_fin@hotmail.com>
Signed-off-by: Jan Kuparinen <copper_fin@hotmail.com>
The virConnectOpen(), well virConnectOpenInternal() reports an
error if embed root is not an absolute path. This is a fair
requirement, but our qemu_shim doesn't check this requirement and
passes the path to mkdir(), only to fail later on, leaving the
empty directory behind:
$ ls -d asd
ls: cannot access 'asd': No such file or directory
$ virt-qemu-run -r asd whatever.xml
virt-qemu-run: cannot open qemu:///embed?root=asd: unsupported configuration: root path must be absolute
$ ls -d asd
asd
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Kristina Hanicova <khanicov@redhat.com>
After cleanup done in v8.2.0-rc1~47 the
qemuDomainObjExitMonitor() and after v8.7.0-rc1~176 the
qemuDomainObjEnterMonitor() lost the @driver argument. But
corresponding ATTRIBUTE_NONNULL() annotation was not removed and
both functions are still annotated as ATTRIBUTE_NONNULL(2) even
though they accept just one argument (@obj).
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Kristina Hanicova <khanicov@redhat.com>
Otherwise looking up a secret fails when we try to elevate the identity
in qemuDomainSecretInfoSetupFromSecret.
https://bugzilla.redhat.com/show_bug.cgi?id=2000410
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Suggested-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The reason why it was in postparse in the first place was so
that we could could automatically enable the secure-boot feature
in some cases, but that no longer happens so we can finally move
it to the proper location.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Now that we're adding information obtained from the firmware
descriptor to the domain XML, this will happen automatically
whenever a firmware that has the enrolled-keys feature ends up
being selected.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Even when the user is not taking advantage of firmware
autoselection and instead manually providing all the necessary
information, in most cases they're still going to use firmware
builds that are provided by the OS vendor, are installed in
standard paths and come with a corresponding firmware
descriptor.
Similarly, even when the user is not guiding the autoselection
process by specifying the desired status of certain features
and instead is relying on the system-level descriptor priority
being set up correctly, libvirt will still ultimately decide to
use a specific descriptor, which includes information about the
firmware's features.
In both these cases, take the additional information that were
obtained from the firmware descriptor and reflect them back into
the domain XML, where they can be conveniently inspected by the
user and management applications alike.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Now that we no longer reject configurations that include both
this information and explicit firmware details, as long of
course as everything is internally consistent, and that we've
ensured that we produce maximally compatible XML on migration,
we can stop stripping this information at the end of the
firmware selection process.
There are several advantages to keeping this information around:
* if the user wants to change the firmware configuration for
an existing VM, they can simply drop the <loader> and
<nvram> elements, tweak the firmware autoselection parameters
and let libvirt pick a firmware that matches on the new
requirements;
* management applications can inspect the XML and easily
figure out firmware-related information without having to
reverse-engineer them based on some opaque paths.
Overall, this change makes things more transparent and easier to
understand. The improvement is so significant that, in a
follow-up commit, we're going to ensure that this information is
available in even more cases.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The combination of explicit firmware paths, which we now
produce in all cases, and firmware autoselection knobs is
explicitly rejected by libvirt 8.6.0 and newer.
Right now we produce inherently migratable XML in all cases,
since we always strip those bits, but that's going to change
soon. To prepare for that, make sure that we always skip the
problematic elements and attributes when preparing a
migratable XML.
The destination will simply receive a fully specified firmware
configuration, which is indistinguishable from one that was
manually provided by the user and is thus accepted by any old
version of libvirt, regardless of whether or not firmware
autoselection was used on the source host.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
libvirt 8.6.0 introduced these checks and very clearly delineated
two possible firmware selection scenarios: manual firmware
selection, where the user is responsible for providing all
information, and firmware autoselection, where a list of desired
features is provided and everything else is handled by libvirt.
In the interest of maintaining the clear separation between these
two scenarios, setting most attributes when firmware autoselection
is active will result in the configuration being rejected.
This works fine, but is unnecessarily restrictive: in most cases,
the additional information that the user has provided matches
the information that libvirt would have discovered on its own by
looking at firmware descriptors, and asking the user to scrub it
from the XML only result in pointless friction.
Remove these checks entirely.
Unsurprisingly, this results in a few test cases that were
rejected until now to suddenly start working and producing
sensible results.
The firmware-auto-efi-loader-path-nonstandard test case is
notable: while we can now enable the xml2xml part of the test,
the xml2argv part is still failing, although in a slightly
different way. This is expected: since the firmware binary is a
non-standard one, libvirt is unable to figure out the missing
information from a firmware descriptor, and the configuration
is still ultimately an invalid one. However, if we were to find
such a configuration on disk at daemon startup, we would not
ignore it completely and instead would offer the user a chance
to fix it.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Right now there are a few scenarios in which we skip ahead, and
removing these exceptions will make for more consistent and
predictable behavior.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The requires-smm feature being present in a firmware descriptor
causes loader.secure=yes to be automatically chosen for the
domain, so we have to avoid this situation or the user's choice
will be silently subverted.
Note that we can't actually encounter loader.secure=no in this
function at the moment because of earlier checks, but that's
going to change soon.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Right now we have checks in place that ensure that explicit
paths are not provided when firmware autoselection has been
enabled, but that's going to change soon.
To prepare for that, take into account user-provided paths
during firmware autoselection if present, and discard all
firmware descriptors that don't contain matching information.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Right now we're checking that firmware descriptor masking works
as intended by creating an empty file matching 60-ovmf-sb.json
in name.
However, that firmware descriptors contains the details for a
perfectly valid and quite common situation: Secure Boot being
supported by the firmware build, but being effectively disabled
by the lack of certificates in the NVRAM template.
Unmask that firmware descriptor, and instead create a dummy one
that has higher priority than all other OVMF builds and points
to paths that are obviously incorrect, which should make it
easy to notice it getting accidentally unmasked in the future.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
These cover the same scenarios as the matching test cases for
autoselection.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
This is identical to the existing
firmware-auto-efi-loader-path-nonstandard test case, but uses
a standard firmware path.
Right now the two test cases behave identically, but that's
going to change in the future.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
This test is intended to simulate the use of an OVMF firmware
image installed under a non-standard path. In order to make
such a configuration work, the user would have to provide
additional information.
Right now it doesn't matter, because the configuration is
rejected anyway, but the behavior is going to change slightly
in the future. Prepare by making the configuration more
complete and realistic.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
This unifies the naming between the manual and automatic
selection cases, clarifies the contents of the tests and makes
room for more tests being added in the future.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
With its version 16.0, the LLVM's linker turned on
--no-undefined-version by default [1]. This breaks how we detect
--version-script= detection, because at the compile time there's
no library built yet that we can use to make --version-script=
happy. Unfortunately, meson does not provide a way to detect this
either [2].
But there's not much sense in detecting the argument either. We
already special case some systems (windows, darwin) and do the
check for others, which are expected to support versioned
symbols, because of ELF. Worst case scenario - the error is
reported during compile time rather than configure time.
1: https://reviews.llvm.org/D135402
2: https://github.com/mesonbuild/meson/issues/3047
Resolves: https://bugs.gentoo.org/902211
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
The function name is already logged, and these can happen only as a
result of a programmer error.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Laine Stump <laine@redhat.com>
Both callers in the VirtualBox driver handle the error and only
call this function with a non-NULL argument.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Laine Stump <laine@redhat.com>
Both callers in the VirtualBox driver error out if the path
can't be fetched via VirtualBox APIs and abort on conversion error
from UTF-16 to UTF-8.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Laine Stump <laine@redhat.com>
over-writing a variable in inner while-loop without freeing previous memory
leaks it over time.
To fix this, we can just change scope of bank variable to the inner loop.
Signed-off-by: Shaleen Bathla <shaleen.bathla@oracle.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Fixes: 5c84485439
Signed-off-by: Ján Tomko <jtomko@redhat.com>
