This was previously used when the plugin was only run on Dell devices.
The plugin was already adjusted to run on other vendor's firmware
but this definition was not removed.
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.
The DW5821e in modem mode uses the 0x81D7 PID, but when it boots in
fastboot mode it uses the 0x81D6 PID. The upgrade procedure was able
to automatically match these two devices because they both shared the
very generic per-VID (0x413C) GUID, but this is no longer operational
since commit 8ef139faba, as the very generic GUIDs have been removed
for matching purposes.
So, define a quirk for the DW5821e, in order to add a counterpart
GUID to make device matching work properly again.
Fixes https://github.com/hughsie/fwupd/issues/1271
If we add or remove a quirk from a machine using the uefi plugin then the new
setting is not used until the BootXXXX EFI key is manually removed. Rather than
just writing the contents of the found key back to the key (doh) just write the
new DP buffer contents if it is different from the previous buffer.
This allows the ODM to specify command line arguments such as:
--flags=use-shim-unique,use-legacy-bootmgr-desc,no-ux-capsule
..which is useful for testing broken firmware.
This difficult to debug bug only showed up when the fwupd service was stopped,
which the user never noticed, but services like abrt were still keen to report.
The root issue was that the call to fu_plugin_get_smbios_data() in
fu-plugin-uefi.c:fu_plugin_startup() was freeing the returned const GBytes,
which rippled down all the way to a double-free deep in libxmlb.
It's somewhat unusual to have a const GBytes, so just change the plugin helper
to returned a ref'd copy, on the logic a potential 16 byte memory leak is better
than a double-free when the next plugin gets the logic the wrong way around.
Fixes https://bugzilla.redhat.com/show_bug.cgi?id=1734746
* Set UpdateError to indicate how the device needs to be updated
* Set the device as needing reboot
* If admin password is set show the message to frontend via `UpdateError`
I'm not 100% sure calling flashrom_programmer_init('internal') unconditionally
on every platform is a very good idea. Only probe the hardware if there is a
whitelisted supported device.
Fixes https://github.com/hughsie/fwupd/issues/1239
Users are getting confused when they're being told that AC power is required
when they are already on AC power... but the battery is too low to perform the
update.
* In startup, check BIOS characteristics for UEFI supported instead of for /sys/firmware/uefi
* In coldplug check for /sys/firmware/uefi
* If /sys/firwmare/uefi missing, create a dummy device telling the user it is in legacy mode
This also means we now include a flashrom subproject as no distro currently has
a flashrom new enough to build the plugin.
Signed-off-by: Richard Hughes <richard@hughsie.com>
Signed-off-by: Artur Raglis <artur.raglis@3mdeb.com>
Signed-off-by: Maciej Pijanowski <maciej.pijanowski@3mdeb.com>
