We use the ParentGuid quirk key to logically 'tie-together' different discrete
devices into one logical device, for instance making the USB soundcard in a hub
the child of the USB controller on the same PCB.
Setting the discrete child is sometimes correct, for instance when rebooting
the hub, the audio device also goes away -- but it's also sometimes wrong.
If we set the child for a discrete device and the parent does *not* go away
then we get to a situation where the child reference may no longer be valid
if it comes back as a different object.
When we try to remove this no-longer-valid device with the removal timeout the
daemon segfaults. This is realy bad.
Continue to allow using fu_device_add_child() in plugins, where we know the
child lifecycle is is matched by the the parent. In the engine just set the
parent ID directly and let the client use this information to show the tree of
logical devices correctly. There's no benefit to setting up the children as
referenced objects anyway.
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
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.
Some Dell devices offer the exact same GUID in UEFI as well as in NVME
plugins. These devices can be flashed in either way, but the payload
for them is different.
The UEFI payload includes relevant headers and metadata to be acceptable
from a capsule. The NVME payload is raw data that the drive will process.
Since baa9e75ca8, fwupd should enforce that
the correct device is flashed with the correct protocol.
Some hardware does not handle upgrading from version 1.2.2 to 1.2.4 and instead
needs to be upgraded from 1.2.2->1.2.3->1.2.4 so that on-device metadata can be
migrated correctly.
Add a new per-device flag `install-all-releases` which causes the daemon to not
skip directly to the newest release. This is designed to be set from a quirk
file.
This can obviously only be used for devices that can apply firmware "live" and
thus do not need a reboot or system shutdown to actually apply the firmware.
This also needs the cabinet archive to ship multiple versions of the firmware,
and for the metainfo.xml file to refer to multiple release objects.
These are devices that we have to be careful with the version numbers, for
instance only updating from versions that have already had data migration
completed.
The new flag can be set in quirk files or on the objects directly.
Add various fixes to enable us to build a selection of useful USB plugins.
Also, skip tests that don't make sense on WIN32 or that will not work.
With much help from Mario Limonciello <mario.limonciello@dell.com> -- Thanks!
We don't actually need either of the things it provides (looking up in source
and built, and converting to an absolute path) so just replace it with
g_build_filename() instead.
This also has the advantage that it does the right thing on Windows.
For composite devices you might want to restrict the child device in respect
to the parent, for instance requiring the parent to have greater than a specific
firmware version number.
The other useful thing to use this for is checking if the parent has a specific
GUID (of any version) which allows us to match against the common VID&PID
instance IDs. This would allow us to restrict a generic child device update to
a specific OEM vendor parent.
This is specified as <firmware depth="1" ...> to match the parent device and
<firmware depth="2" ...> to match the grandparent device.
The root of this problem is that we were trying to use pending.db as both a
pending report store and also a record of history, so you could see updates for
device foo 1.2.3->1.2.4 and then 1.2.4->1.2.5.
This sort-of half worked, but it meant in some cases we matched on the old
device version, sometimes on the new release version and sometimes matching on
either.
The problem was that in various places we were using the device ID as *the*
primary key, and so we had various functions like fu_history_get_device_by_id()
that expected to return just one device, not several.
The device ID also changes if the device is moved from USB plug to another, and
so it got even more complicated again trying to de-dupe the devices.
The sanest thing to do is to decide that pending.db only contains the latest
attempt to go from one version to another using device-id as the primary key.
This makes reporting work reliably now, although has the effect you can't
report a 1.2.3->1.2.4 and 1.2.4->1.2.5 at the same time. Note, if you tried to
do the latter before, the update-error (if set) would be wrong on the second
report...
For the 1.3.3 release make it all simpler and so the reporting works reliably.
Longer term we can design a better database schema that uses unique ID to
represent the *transaction* itself, that isn't tied to the device ID in any way.
This might mean extending the DBus API to cope with multiple devices being
returned with the same device-id set.
During startup we do 1898 persistent allocations to load the quirk files, which
equates to ~90kb of RSS. Use libxmlb to create a mmap'able store we can query
with XPath queries at runtime.
Currently the test runs for 100ms and looks to see that at least 8 times
the poll function callback hit.
This normally works well enough, but during self tests it depends upon
too much timing and leads to failures sometimes:
```
** (/<<PKGBUILDDIR>>/obj-s390x-linux-gnu/src/fu-self-test:50432): DEBUG: 15:37:55.189: poll cnt=0
*# DEBUG: poll cnt=1
** (/<<PKGBUILDDIR>>/obj-s390x-linux-gnu/src/fu-self-test:50432): DEBUG: 15:37:55.199: poll cnt=1
*** (/<<PKGBUILDDIR>>/obj-s390x-linux-gnu/src/fu-self-test:50432): DEBUG: 15:37:55.209: poll cnt=2
** (/<<PKGBUILDDIR>>/obj-s390x-linux-gnu/src/fu-self-test:50432): DEBUG: 15:37:55.227: poll cnt=3
*# DEBUG: poll cnt=4
** (/<<PKGBUILDDIR>>/obj-s390x-linux-gnu/src/fu-self-test:50432): DEBUG: 15:37:55.255: poll cnt=4
*# DEBUG: poll cnt=5
** (/<<PKGBUILDDIR>>/obj-s390x-linux-gnu/src/fu-self-test:50432): DEBUG: 15:37:55.267: poll cnt=5
Bail out! ERROR:../src/fu-self-test.c:3489:fu_device_poll_func: assertion failed (cnt >= 8): (6 >= 8)
--- stderr ---
**
ERROR:../src/fu-self-test.c:3489:fu_device_poll_func: assertion failed (cnt >= 8): (6 >= 8)
-------
```
Mark this as a slow test so that it doesn't cause CI failures.
We don't need to enumerate USB and UDev devices in the self tests. In the case
where the probe fails (due to a permissions error, as not running as root) we
don't want the tests to fail.
At least two vendors are not using SREC according to the spec. They are using
it like a recipe to write specific values at specific addresses.
All the logic like line lengths and checksumming (and therefore all the various
checks for malicious firmware) are still valid, so provide a new function to
just tokenize the file and to not assign a padded image.
There are several subtle bugs in various places in fwupd caused by not treating
user-provided offsets into buffers as unsafe. As fwupd runs as root we have to
assume that all user firmware is evil, and also that devices cannot be trusted.
Make a helper to put all the logic into one place and convert all users.
In many plugins we've wanted to use ->prepare_firmware() to parse the firmware
ahead of ->detach() and ->write_firmware() but this has the limitation that it
can only return a single blob of data.
For many devices, multiple binary blobs are required from one parsed image,
for instance providing signatures, config and data blobs that have to be pushed
to the device in different way.
This also means we parse the firmware *before* we ask the user to detach.
Break the internal FuDevice API to support these firmware types as they become
more popular.
This also allows us to move the Intel HEX and SREC parsing out of the dfu plugin
as they are used by a few plugins now, and resolving symbols between plugins
isn't exactly awesome.
One test verifies a firmware with a signature from the old LVFS which was
hosted on secure-lvfs.rhcloud.com and used the original PKCS-7 key. This key
had a two year validity (expiring today, ohh the naivety...) rather than the
newer fwupd.org key which expires in the year 2058.
For this specific test only, disable the certificate time checks to fix CI.
Fixes https://github.com/hughsie/fwupd/issues/1264
This leads to madness, as some formats are supersets of the detected types,
e.g. 'intel-me' is detected as 'quad' and 'bcd' is detected as 'pair'.
Where the version format is defined in a specification or hardcoded in the
source use a hardcoded enum value, otherwise use a quirk override.
Additionally, warn if the version does not match the defined version format
This is arguably the more correct fix, regardless of the UEFI quirk use as each
release was reading and converting the exact same property from the component.
Fixes https://github.com/hughsie/fwupd/issues/1156
