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
Only use the history database to tell if activation should be run.
Instead query the connected devices to find the ones needing activation.
This should allow non-connected devices to not cause a failure (although
it might be a longer shutdown).
Also sort the devices, so that the order follows the defined order from
the daemon and they activate in the same order they install.
When one result is obsoleted by another, then do not show the old result by
default.
Additionally hide the HSI URLs as this was designed more for GUI clients like
gnome-firmware than CLI tools such as fwupdmgr.
This changes allows for downloading firmware from a remote server
pointed from a local remote manifest.xml.gz file
Change-Id: Id00870f9c2817d48d6d301d2b6d229ba1ca6045a
At the moment we just blindly assume the capabilities of the front-end client
when installing firmware. We can somewhat work around by requiring a new enough
fwupd daemon version, but the client software may be older or just incomplete.
This would allow, for instance, the firmware to specify that it requries the
client to be able to show a detach image. This would not be set by a command
line tool using FwupdClient, but would be set by a GUI client that is capable
of downloading a URL and showing a PNG image.
Clients that do not register features are assumed to be dumb.
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.
This fixes the confusing case where installing the CCGX firmware on a dock
would reboot the hub, leading to this output:
Installing on USB-I2C Bridge… ]
Installing on USB2.0 Hub…[************************************** ]
Installing on USB3.1 Hub…[************************************** ]
Installing on USB2.0 Hub…[************************************** ]
Installing on USB3.1 Hub…[************************************** ]
Installing on ThinkPad USB-C Dock Gen2 USB Audio…*************** ]
Installing on USB-I2C Bridge…*********************************** ]
Restarting device… [***************************************]
With the patch, this is now:
Installing on USB-I2C Bridge… ]
Restarting device… [***************************************]
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
Resolves installation for local CAB files that have `VersionFormat`
set but not yet also set from metadata.
In the first pass ignore the version format. This will rule out all
other checks such as GUID and protocol.
Then apply version format to the device if specified in the CAB.
Lastly do a second pass with all requirements set.
