Most vendors do not mirror the firmware update to an external display,
and some don't behave correctly when the lid is shut and the machine is
docked. Add this quirk just for Lenovo for now.
Fixes https://github.com/fwupd/firmware-lenovo/issues/181
A UF2 device exposes a VFAT block device (sometimes called a Mass
Storage Device) which has a virtual file called `INFO_UF2.TXT` where
metadata can be read. It may also have a the current firmware exported
as a file called `CURRENT.UF2` which is in a 512 byte-block UF2 format.
Writing any file to the MSD will cause the firmware to be written.
Sometimes the device will restart and the volume will be unmounted
and then mounted again. In some cases the volume may not “come back”
until the user manually puts the device back in programming mode.
Match the block devices using the VID*PID, UUID or label, and then
create a UF2 device which can be used to flash firmware.
Note: We only read metadata from allow-listed IDs to avoid causing
regressions on non-UF2 volumes. To get the UUID and label you can
use commands like:
udisksctl info -b /dev/sda1
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.
The CRC32 and CRC16 algorithms have "full" functions that allow callers to
provide their own polynomial and initial CRC value. Provide the same ability
to users of the CRC8 algorithm.
Additionally, if the client does not set the feature flag `fde-warning`,
add an extra paragraph into the update description.
Fixes https://github.com/fwupd/fwupd/issues/3829
This moves the cached metadata location from /var/lib/fwupd/remotes.d
to /var/lib/fwupd/metadata
The former was a bad name as it wasn't a list of remotes, and .d is the
suffix for directories the user can install files into, rather than for
binary content managed entirely by the daemon.
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
The kernel allows configuring this, and certain plugins will use this
path to be able to load firmware in the kernel driver through runtime,
but to flash to the device.
Until gi-docgen is declared stable support either of them.
This effectively means that hand builds and CI builds will use
gi-docgen, but distro builds use gtk-doc-tools.
There is no Manager object, so block devices must be discovered
manually.
Additionally, Type field contains FS name rather than its MBR ID in
hex form or a GPT GUID.
Signed-off-by: Richard Hughes <richard@hughsie.com>
This allows for proper locking between executions of fwupdtool in
Chromium OS minijail environment. It is needed after commit
9cf5f8f7ff was introduced.
Change-Id: I37b33c8d1fbe97ec9baddc5f77ea94e2f4ff1fa4
This allows plugins to set the battery power state of the *machine* which means
we can automatically inhibit devices with FWUPD_DEVICE_FLAG_REQUIRE_AC set.
It also allows to set the BatteryThreshold to 25% for Lenovo hardware, and we
can override other vendors with further quirks as required.
Fixes https://github.com/fwupd/fwupd/issues/3084
This makes a lot more sense; we can parse a firmware and export the same XML
we would use in a .builder.xml file. This allows us to two two things:
* Check we can round trip from XML -> binary -> XML
* Using a .builder.xml file we can check ->write() is endian safe
