Saving the quirks in the GResource section worked well, but it made the build
system very complicated and also meant the .data section was duplicated in
both `fwupd` and `fwupdtool` -- negating a lot of the hard-fought savings.
Simplify this feature so that we just `cat` all the quirk files together, then
gzip them into a single file. This means that at startup fwupd only needs to
check the mtime of one file, and weirdly it's actually faster to load a smaller
compressed file from disk that it is to load multiple uncompressed files.
In case no version is found, android-boot plugin uses a fall back
version (0.0.0) but no version format is set. Therefore, fwupd uses
format 'plain' as default which is not correct as 0.0.0 is a triplet.
If a specific plugin calls fu_plugin_set_secure_config_value() and then
fu_plugin_set_config_value() then we'll save the file with the world-readable
permissions.
Set a plugin flag to say that 'this plugin is storing sensitive details' which
allows us to use the same entrypoint and also fix up any files at startup that
do not have the correct permissions.
We now have two plugins getting the ESP values, and we only allow hardcoding
the ESP in uefi_capsule.conf.
Make all this a lot simpler by moving the ESP+BDP code to `FuContext`, which
also means we can handle the override (via the config file) in the engine,
and the override (in the command line tools) using the same mechanism.
Also, automate the migration of the `OverrideESPMountPoint` -> `EspLocation`
when loading the engine.
Fixes https://github.com/fwupd/fwupd/issues/5042
Make the IPMI auto-account feature allow-listed on specific vendors as some IPMI
implementations are not specification compliant and do entirely the wrong thing.
Although typically we set the password using fu_plugin_set_secure_config_value()
or something like Ansible or Puppet -- the user could just edit the file with
vim and we still want the permissions set correctly.
The kernel will issue a CPUID of 0x1 before reading microcode.
Align this behavior with the MSR plugin.
AMD and Intel align their microcode diffrently in MSR 0x8b.
* Intel it's 4 bytes in.
* AMD it's at the start of the MSR.
In general this is a cleanup, means less vfuncs that get called when
devices are added. Beyon the optimization functionally should be a
no-op for fwupd. It will also potentially storing the version
to the newly created secure processor device in the future.
Pine64 PinePhone Pro has an SPI device which is handled by the MTD
plugin and comes with Tow-Boot pre-installed from the factory.
Expose it as Tow-Boot and mark the firmware type with uSWID for version
extraction. However, it does not provide uSWID data so users have to manually
upgrade to a Tow-Boot version with uSWID data support first.
The coSWID is a child of the parent, and the parent container does not have a
version. Also fix a small memory leak when parsing container formats.
Fixes https://github.com/fwupd/fwupd/issues/4294
the autopkgtest environment in Ubuntu seems to not be preparing the mtdram
device properly. Sometimes the udev node "exists" but the /dev/mtd0 does not
exist.
Look for this explicitly and skip the test if it happens.
It's true that the USB4 spec won't require x86, but a recent autopkgtest
failure on powerpc doesn't make sense to debug. You won't ever see TBT
in a powerpc machine.
We can loosen this to any non-x86 architectures later that DO prove to
have support for USB4 add-in cards.
