Some parsers are ignoring the magic when using _FLAG_IGNORE_CHECKSUM
(which is wrong; fuzzers have no problem with enforcing a static prefix)
and other either disregard the offset or check the magic in an unsafe
way. Also, use FWUPD_ERROR_INVALID_FILE consistently for magic failure.
Add a vfunc, and move all the clever code into one place.
Some plugins were creating local versions (which were not attached to
the daemon progress in any way) as a workaround as they needed to do
actions that took a long time to complete.
tristate features will automatically disable if dependencies marked
as required are missing.
Packagers can manually override using `auto_features`.
Link: https://mesonbuild.com/Build-options.html#features
We now have 9 different plugins all using this functionality, and we're
about to add one more. Move this into common code so that all the
plugins are using the same endian and bufsz-safe versions.
We were calling g_module_symbol() 2703 times, which is actually more
expensive than you'd think.
It also means the plugins are actually what we tell people they are:
A set of vfuncs that get run. The reality before that they were dlsym'd
functions that get called at pretty random times.
Wacom has begun migrating its current Intuos product line to a new
Bluetooth chipset. This new revision uses new PIDs as well so we
need to update the quirks list.
Wacom is beginning to integrate a new Bluetooth chipset in their
devices. This chipset uses a somewhat different flash protocol
and requires the creation of a new fwupd module. Chipsets using
this new protocol are identified in the firmware descriptor with
ID 0x06, leading to our choice of module name: "bluetooth-id6".
The new chipset is first appearing in a minor update to the Wacom
Intuos (CTL-4100WL/CTL-6100WL) line. These devices do not support
the firmware descriptor interface, requiring us to statically assign
it as a module in the legacy codepath if any Bluetooth support is
found. This clutters the output of the `get-devices` command but the
update CAB files ensure the correct module is used depending on PID.
Timeout characteristics of the start/data/end commands can vary between
modules. Rather than leaving `fu_wac_module_set_feature` responsible for
setting a globally-reasonable timeout, allow the callers to specify a
locally-optimal value instead.
We only had to pile everything into the src/fuzzing/firmware directory
because honggfuzz could not cope with more than one input path.
This way each plugin is self contained and easy to copy.
Also, install the fuzzing builder objects as this fixes the installed
tests when srcdir does not exist.
Based on a patch by Jan Tojnar <jtojnar@gmail.com>, many thanks.
This allows us to override the location we load data files from, which
allows us to do more kinds of installed tests in the future.
Also, move the global data/tests content into the place that it is used
as it was getting impossible to manage.
Using fu_common_strnsplit() has the drawback that a malicious user (or
a fuzzer!) could create a file with 5,000,000 newlines, and then pass
that into any parser that tokenizes into lines. This causes millions of
tiny allocations and quickly dirties hundreds of megabytes of RSS due
to heap overheads.
Rather than splitting a huge array and then processing each line, set
up a callback to process each line and only allocate the next string if
the token was parsed correctly. This means that we don't even dup the
buffer before we start parsing, rather than allocating everything and
then failing at the first hurdle.
Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=38696
It's actually quite hard to build a front-end for fwupd at the moment
as you're never sure when the progress bar is going to zip back to 0%
and start all over again. Some plugins go 0..100% for write, others
go 0..100% for erase, then again for write, then *again* for verify.
By creating a helper object we can easily split up the progress of the
specific task, e.g. write_firmware().
We can encode at the plugin level "the erase takes 50% of the time, the
write takes 40% and the read takes 10%". This means we can have a
progressbar which goes up just once at a consistent speed.
More than one person has asked about 'why call fu_plugin_update() for a
reinstall or downgrade' and I didn't have a very good answer.
The plugin API is not officially stable, and we should fix things to be
less confusing. Use the same verbs as the FuDevice vfuncs instead.
Both the wired-only and wireless-capable versions of the CTL-4100 /
CTL-6100 will switch into "Android mode" if their string descriptors are
read too many times. A previous commit added the "no-serial-number"
flag to the wireless variants to work around this problem; this commit
adds the flag to the wired-only variants.
While the modern firmware interfaces report their version numbers in
big-endian form, reading the legacy Bluetooth module version via the
FU_WAC_REPORT_ID_GET_FIRMWARE_VERSION_BLUETOOTH report requires us to
actually parse a little-endian value. This difference was overlooked
when making changes to the version parsing code in commit 50a4ec70e6.
This commit restores the proper interpretation.
Fixes: 50a4ec70e6 (wacom_usb: Firmware versions are packed BCD, not "decimal")
Before this change calling FuUsbDevice->open() opened the device, and
also unconditionally added various GUIDs and InstanceIDs which we
normally do in setup.
Then fu_device_setup() would call the FuSubclass->setup() vfunc which
would have no way of either opting out of the FuUsbDevice->setup()-like
behaviour, or controlling if the parent class ->setup is run before or
after the subclass setup.
Split up FuUsbDevice->open() into clear ->open() and ->setup() phases
and add the parent class calls where appropriate.
This means that ->setup() now behaves the same as all the other vfuncs.
