Conceptually we were trying to stuff subtly different actions into one vfunc:
* Read firmware from the device to update the verification checksums
* Read a firmware blob from the device for debugging
For the first action we might want to mask out the sections of the flash with
serial numbers (so the verification hashes match the ones published on the LVFS)
and for the second we want just a raw ROM file from the hardware with no
pre-processing that we can compare against an external SPI dumper.
Split out ->dump_firmware to get the raw blob, and allow plugins to also
implement ->read_firmware() if they have to mask out specific offsets or remove
specific images from the FuFirmware container.
In the common case when masking is not required, fall back to using a 'binary'
FuFirmware automatically to make most plugins simpler.
At the moment there are commands to convert one file format to another, but not
to 'merge' or alter them. Some firmware files are containers which can store
multiple images, each with optional id, idx and addresses.
This would allow us to, for instance, create a DfuSe file with two different
raw files that are flashed to different addresses on the SPI flash. It would
also allow us to create very small complicated container formats for fuzzing.
This can be used by writing a `firmware.builder.xml` file like:
<?xml version="1.0" encoding="UTF-8"?>
<firmware gtype="FuBcm57xxFirmware">
<version>1.2.3</version>
<image>
<version>4.5.6</version>
<id>header</id>
<idx>456</idx>
<addr>0x456</addr>
<filename>header.bin</filename>
</image>
<image>
<version>7.8.9</version>
<id>payload</id>
<idx>789</idx>
<addr>0x789</addr>
<data>aGVsbG8=</data>
</image>
</firmware>
...and then using something like:
# fwupdtool firmware-convert firmware.builder.xml firmware.dfu builder dfu
For containers with multiple images it is sometimes very helpful to know what
file they've been loaded from. This would also allow us to 'explode' the
firmware container into seporate image files on disk.
The function fu_firmware_add_image() has the comment text 'If an image with the
same ID is present it is replaced' which has not been true for some time.
This was removed, as the common case of adding two images with no ID would only
leave one. However, some plugins do actually want to dedupe on the ID or IDX,
so provide a flag they can set which enables this functionality without
introducing regressions into other plugins.
This resulted in losing g_usb_source_set_callback@LIBGUSB_0.1.0 which causes a
build failure when building gusb as a subproject, and also the little-used
fu_chunk_to_string() from libfwupdplugin.
Signed-off-by: Richard Hughes <richard@hughsie.com>
At the moment at startup we're calculating the attrs so we can export the HSI
string property on the D-Bus interface. Running `fwupdtool security` actually
gets all the security attributes at least twice!
fmap is a Google flash layout format that is used in several of Google's
firmware projects, including Chrome OS Embedded Controller and the Chrome OS
coreboot firmwares. Introduce it as a firmware format in libfwupdplugin.
Add two new vfuncs that can be used to collect report metadata from devices
both before and after the update has run. This means we can remove the hacks
where we set add 'global' metadata entries and just hope that there is only one
device from the same plugin that is updated.
This also allows us to collect debugging metadata from devices after an offline
update has been run.
This exports FuSecurityAttrs into libfwupdplugin so that we can pass the plugins
this object rather than a 'bare' GPtrArray. This greatly simplifies the object
ownership, and also allows us to check the object type before adding.
In the future we could also check for duplicate appstream IDs or missing
properties at insertion time.
This change also changes the fu_plugin_add_security_attrs() to not return an
error. This forces the plugin to handle the error, storing the failure in the
attribute itself.
Only the plugin know if a missing file it needs to read indicates a runtime
problem or a simple failure to obtain a specific HSI level.
The HSI specification assigns a simple text ID to the current state of firmware
security. As new vulnerabilities are found, and as protection measures are
updated, new requirements will be added to the required firmware behaviours for
each HSI value.
The HSI specification is currently incomplete and in active development, and
so the --force flag is required in all command line tools. The current ID value
will probably change on a given platform so please do not start using the result
for any kind of compliance requirements.
We're planning to ship fwupd 1.4.x in RHEL 8 and so it makes sense to have a
stable branch to do point releases. I don't intend to release versions 1.5.x
any time soon, so moderately-agressive backporting to 1_4_X is okay.
Sometimes plugins need to retry various commands send to hardware, either due
to unreliable transfers (e.g. using USB bulk) or from slightly quirky hardware.
Between them they seem to get various things wrong; either the error messages
are repeated and thus difficult to parse, or they just get the memory handling
of `g_propagate_prefixed_error()` wrong.
Providing sane helpers we can reduce the amount of boilerplate. Additionally
we can support a 'reset' function that can try to automatically recover the
hardware for specific error domains and codes.
A Jcat file can be used to store GPG, PKCS-7 and SHA-256 checksums for multiple
files. This allows us to sign a firmware or metadata multiple times (perhaps
by the OEM and also then the LVFS) which further decentralizes the trust model
of the LVFS.
The Jcat format was chosen as the Microsoft catalog format is nonfree and not
documented. We also don't want to modify an existing .cat file created from WU
as this may make it unsuitable to use on Windows.
More information can be found here: https://github.com/hughsie/libjcat
Quite a few plugins use HID commands to communicate with the hardware. At the
mement we have ~6 implementations of SET_REPORT and are soon to add one more.
Move this into common code.
If the measurements are missing but it's a UEFI system, it's a good indication
that the user has secure boot turned off.
Notify the user on the UEFI device through a non-fatal `UpdateMessage`
To accomplish this, move fu-uefi-vars into the plugin library for other plugins to use
Replace fu_common_cab_build_silo() with an actual GObject that can hold parsing
state. This cleans up the code a lot, and means we can add additional
functionality in the future without breaking ABI or API.
The long term plan is to verify the metadata and payload signatures when
parsing FuCabinet, rather than much later in _check_requirements().
This of course requires passing in a keyring context (which we don't yet have)
and would mean we can stop setting the various confusing 'fwupd::ReleaseBlob'
XbNode extra data.
No logic changes for now, just a lot of moving things into sane places.
If we say that the version format should be the same for the `version_lowest`
and the `version_bootloader` then it does not always make sense to set it at
the same time.
Moving the `version_format` to a standalone first-class property also means it
can be typically be set in the custom device `_init()` function, which means we
don't need to worry about *changing* ther version format as set by the USB and
UDev superclass helpers.
In 1de7cc we checked the version format when checking for update, but there are
many other places that are doing verfmt-insensitive comparisons. For instance,
the predicates in <requires> all fail if the device version format is plain.
his breaks updating some NVMe drives where the `ne` requirements are not
semantic versions.
To avoid trying to catch all the bugs in different places, and in case we have
a future verfmt that should be treated another way, refactor this out in to a
common function and deprecate the old function.
Sometimes the plugin will want to influence the subclassed device, for instance
by reading a per-plugin config file. At the moment there's no way to do this,
as even _device_registered() is explicitly designed for devices *not* created
by the plugin itself.
Even if _device_registered() was changed to include the plugin creating the
object it would still happen well after the device has done _probe() and/or
_setup() and would probably be too late to do anything useful.
