Some logitech devices seem to reboot immediately and the failures then
look like a broken pipe, but are actually the device rebooting.
If the device really did fail to detach after the timeout is done we'll
see a message that the device failed to come back instead.
Deleting boot entries from EFI sometimes triggers problems on some firmware.
We don't actually need to do it from the EFI binary, and it's perfectly safe to
leave it in the boot list. It also means when doing multiple updates over
several months we're not creating, deleting, creating, deleting and can just
re-use the same BootXXXX number each time.
It also makes the EFI binary simpler, which is good.
At the moment fwupd creates a BootXXXX for fwupd.efi and marks it BootNext.
It *also* adds it to the end of BootOrder to work around various old firmware
bugs like https://github.com/rhboot/fwupdate/issues/55 which we can perhaps
drop sometime thie century.
Remove the rewriting of BootOrder from the EFI binary; we've accidentally not
been doing it for a long time and nothing broke, and I'd like to make the EFI
binary as small and simple as possible. The user can remove the entry from the
BIOS or using efibootmgr if required, but it's harmless to just leave it.
This reverts commit 44f55e2ee6.
This behavior caused fwupdx64.efi to loop for a very long time until
either aborting, running out of memory or some other problems.
Fixes: #1756Fixes: #1751
The guint16 was promoted to (signed) int for the multiplication, which meant
that the highest address possible was 0x7FFFFFFF not 0xFFFFFFFF. Which doesn't
really matter in reality, as all addresses are much smaller than that now.
gnu-efi 3.0.11 moves a few files around, e.g.
/usr/lib64/gnuefi/elf_x64_efi.lds -> /usr/lib64/gnuefi/x64/efi.lds
...and this causes the UEFI EFI helper to fail to link.
Add support for the 'new' paths and fall back to the old ones.
Fixes https://github.com/fwupd/fwupd/issues/1736
In some composite dock hardware there are two USB devices exported to the host,
both with the same VID:PID values. We need to use the device type (e.g. VL812B3)
to differenciate the devices and install the correct fw on the correct device.
In theory, these should always match the reported PCRx values from the TPM.
If the reconstructed event log checksum does not match the TPM value then
something is either implemented wrongly, or something bad has happened.
This means we use half the amount of memory to store the event hashes, and also
means we can process the raw data in future patches without parsing back out
of ASCII format.
UEFI runtime service GetVariable with DataSize NULL, will fail and get
EFI_INVALID_PARAMETER returned. Set DataSize 0 and allocate the buffer for
getting attributes for the deleted variable.
Also, fix the real reason Boot#### was never found.
Synaptics versions are encoded as BCD, the largest version that will
ever be represented in this field is '99'.
Using 3 digits in this field has caused multiple problems in upgrades from
LVFS.
1. Devices are being upgraded when not necessary.
IE `5.3.10 > 5.3.010`
2. Device upgrades are deemed failures as follows:
```
BootTime=1571436076,
CompileVersion(com.redhat.efivar)=37,
CompileVersion(com.redhat.fwupdate)=12,
CompileVersion(org.freedesktop.fwupd)=1.3.2,
CompileVersion(org.freedesktop.gusb)=0.3.0,
CpuArchitecture=x86_64,
DistroId=fedora,
DistroVariant=workstation,
DistroVersion=32,
FirmwareId=1915,
Flags=4194346,
Guid=f15aa55c-9cd5-5942-85ae-a6bf8740b96c,
MachineId=97aa89528b88d9631867a4e20c68a5208124ef592e19d05f0c5e7d22bd4d7afb,
Plugin=synapticsmst,
RuntimeVersion(com.dell.libsmbios)=2.4,
RuntimeVersion(com.redhat.fwupdate)=12,
RuntimeVersion(org.freedesktop.appstream-glib)=0.7.14,
RuntimeVersion(org.freedesktop.fwupd)=1.3.2,
RuntimeVersion(org.kernel)=5.4.0-0.rc2.git2.1.fc32.x86_64,
UpdateError=device version not updated on success, 05.03.10 != 5.03.010,
UpdateState=failed,
VersionNew=05.03.10,
VersionOld=5.03.010
```
There's no reason to prevent NULL, and doing so means the caller has to check
before setting the value. Only one subclassed type was actually doing this...
No need to fail these self tests when using amdgpu, just skip them.
Fixes unrelated issue found in #1183
Signed-off-by: Richard Hughes <richard@hughsie.com>
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.
To implement the SPI commands, objects can derive from FuVliDevice and
implement the new vfuncs. This allows us to override the implementation for
minor API changes.
Right now vendor string is detected by walking up the udev chain
until a vendor is found. On some systems this is finding incorrect
data such as `Intel Corporation` for the vendor on the touchpad.
As the plugin only supports Synaptics devices, Correct it by hardcoding
vendor to `Synaptics`.
Sample output:
```
└─Touchpad:
Device ID: b26933c085b020ecf84c490812458523aee710ac
Current version: 1.5.2767034
Bootloader Version: 54.0
Vendor: Synaptics (HIDRAW:0x06CB)
GUIDs: f4384034-9243-5334-8075-a534be913e46 ← HIDRAW\VEN_06CB&DEV_76AF&REV_00
424bd00e-9789-5cdf-a12a-3c81bc4676d6 ← HIDRAW\VEN_06CB&DEV_76AF
140f4458-951b-5bb9-85e2-879bd5b02615 ← SYNAPTICS_RMI\TM3038-003
b29d3c85-cd0e-503e-9c7e-f6731c1eaf2d ← SYNAPTICS_RMI\TM3038
Device Flags: • Internal device
• Updatable
```
Dell does not include the first byte in the ESRT value, ignoring it. Using a
`quad` means we get versions like `0.1.4.0` rather than `1.4.0` which confuses
both users comparing versions to the vendor website, and also anyone trying to
do analysis on the firmware.
Only on Lenovo devices the DMI version string is prefixed with
CBETxxxx to make the thinkpad_acpi kernel module happy.
Add a new quirk called "CorebootVersionQuirks" to detect platforms
that need to cut of the prefix.
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
In fu_plugin_startup we make sure that the FU_HWIDS_KEY_BIOS_VENDOR
matches "coreboot", so there's no need to read it again.
Remove the call to fu_plugin_get_dmi_value and drop the first call
to fu_device_set_vendor as it gets overwritten below.
Hardcode the id string for now.
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
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.
Some plugins have devices with more than one protocol. Logically the protocol
belongs to the device, not the plugin, and in the future we could use this to
further check firmware that's about to be deployed.
This is also not exported into libfwupd (yet?) as it's remains a debug-feature
only -- protocols are not actually required for devices to be added.
This support was using the wrong commands to add a HWID and thus
never actually functioned. Furthermore it's purpose is to pull
the PID out of the bootloader to be able to properly identify
the device when in bootloader mode (as in recovery mode).
When in this state, generate the correct instance IDs for both
possible Wacom VID. We can't tell which Wacom VID we are in
bootloader mode.
This makes everything simpler, at the expense of not being able to create a
`BootFFFF` entry -- but if we get that far something has already gone very
wrong with the firmware...
Some derivative distributions re-use bootloader paths from their
upstream. When this happens the current logic to look for the `ID`
key in `/etc/os-release` doesn't work properly.
Adjust the logic to:
1) Use `ID`
2) Test the path exists. If so, use it.
3) If it doesn't use `ID_LIKE`.
4) Test if that path exists, if so use it.
5) If that path doesn't exist, return the key from `ID`
6) The plugin will make this path.
This fixes a regression introduced by 2031ce3bf6
that leads to:
```
USB error on device 2dc8:5750 : No such device (it may have been disconnected) [-4]
```
The GNU gold linker uses the section name `.rela.dyn` instead of
`.rela` for containing the relocation information. If this section
is not copied the EFI executable can crash.
Fixes#1530
In an error block that checks for `NULL` sysfs, you will always see
`(null)` in the string.
```
FuPluginThunderbolt Unable to read generation: failed get id generation for (null)
```
This device was showing up from a LG 38UC99-W USB-C monitor
```
VMM0000:
Device ID: d762543f8c20f636e6fff031a000078d3e10c600
Summary: Multi-Stream Transport Device
Current version: 0.00.000
Vendor: Synaptics
GUIDs: 42addef4-40f9-5e89-b925-d564e35ed368 ← MST-(null)-vmm0000-0
cf8c03c5-18bf-53c4-971f-4a08f88932b5 ← MST-(null)-0
e9427b6a-7389-5461-a592-1da5f8ec99fd ← MST-(null)
Device Flags: • Updatable
```
```
failed to close device: Bad file descriptor
```
fu-udev-device will open a locker automatically now.
However synaptics-rmi closes the file descriptor on it's own with `g_clear_object`.
So destroy the fd in synaptics-rmi.
Set `IS_BOOTLOADER` unconditionally when in fastboot mode. This seems logically
what it is; a degraded mode that's able to update firmware without runtime
functionality.
Fixes https://github.com/fwupd/fwupd/issues/1532
This allows us to do three things:
* Fuzz the loader with `fwupdtool firmware-parse`
* Check the firmware *before* the hardware is put into bootloader mode
* Use FuChunk to build the 32 byte payload chunks
Systems with multiple host controllers will most likely have a different
NVM image for each controller but there is no guarantee that the device_id
within the NVM image varies from one controller to another.
To account for this, build a GUID that contains the last element of the
Thunderbolt controller's udev path.
Sample GUID strings from an XPS 9380 (which only contains one host controller):
```
Guid: 0f401ed2-b847-532a-adc8-3193fc737be6 <- TBT-00d408af-native
Guid: 420b0596-f5cb-5fd7-8416-c99d48ad8de9 <- TBT-00d408af-native-0000:05:00.0
```
This commit follows the presumption that the kernel will enumerate the controllers
in the same order every time.
This also lets us remove the call to dfu_device_wait_for_replug() which was
causing a deadlock due to unsafe main context usage. Splitting the code allows
us to use the device list to watch for replug, without adding even more Jabra-
specific plugin code to the DFU plugin.
Looking at this with a 40,000ft view, the Jabra runtime really doesn't have
much in common with DFU and the reason it was originally all lumped together
was that the daemon couldn't "change" plugins between detach and update.
It's unfortunate that we have to include a sleep() in the DFU code after the
DFU probe, but this is specified by Jabra themselves. Attempting to open the
device without waiting reboots the hub back into runtime firmware mode, so we
can't even retry the failing setup action.
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.
We can't use the IOTA mechanism in bootloader mode, and failing to create the
FuSynapromDevice object means we can't recover the hardware if the flash failed.
Some devices don't set the CAN_DOWNLOAD attribute in their runtime descriptor.
Rather than quirk these devices just assume that all DFU devices with a DFU
interface can download in DFU mode. The logic being, why would they expose a
runtime DFU interface if they can't download new firmware in DFU mode...
Devices like the DW1820A that are currently blacklisted because of broken DFU
support will remain blocked with this change.
This makes the daemon less destructive at startup, especially if the ESP
is not mounted.
It's stored in 3 different places right now, so move it into one point of truth.
Now the ESP is detected when needed including all point of time safety checks and
dynamically mounted and unmounted if necessary.
It appears to only happen on non-dell systems trying to look up system
ID through `sysinfo_get_dell_system_id`
Other than CI non-dell systems won't be running this code.
Detect and parse current coreboot version.
There's no need to depend on libflashrom for now.
An update mechanism isn't implemented as the kernel interface isn't
stable yet and will be implemented in a separate commit.
Tested on coreboot enabled machine.
Example output:
coreboot System Firmware
DeviceId: 81104bde9db7cb037936659ea727c739f47a5029
Guid: 230c8b18-8d9b-53ec-838b-6cfc0383493a <- main-system-firmware
Guid: de6fd40f-4ec9-5c0b-95e1-8fb13d1b030c <- LENOVO&ThinkPad T410&2537VG5
Guid: 978b0d18-bfe9-5279-9a9f-68dc247a705f <- LENOVO&ThinkPad T410&LENOVO&2537VG5
Summary: Open Source system boot firmware
Plugin: coreboot
Flags: internal|registered
Vendor: LENOVO
Version: 4.10.991
VersionFormat: triplet
Icon: computer
Created: 2019-10-14
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
If calling `ch_strerror` with some values returns `NULL` which makes
the `GError` not get populated.
```
0 0x00007f252d64d3bd in fu_colorhug_device_attach (device=0x560d7b5c4520 [FuColorhugDevice], error=0x7ffc57a51040) at ../plugins/colorhug/fu-colorhug-device.c:200
1 0x0000560d7a398279 in fu_device_attach (self=0x560d7b5c4520 [FuColorhugDevice], error=0x7ffc57a51040) at ../src/fu-device.c:1988
2 0x0000560d7a3a4b6c in fu_plugin_device_attach (self=0x560d7b57e160 [FuPlugin], device=0x560d7b5c4520 [FuColorhugDevice], error=0x7ffc57a51040) at ../src/fu-plugin.c:856
3 0x0000560d7a3a553f in fu_plugin_runner_device_generic
(self=0x560d7b57e160 [FuPlugin], device=0x560d7b5c4520 [FuColorhugDevice], symbol_name=0x560d7a3d4258 "fu_plugin_update_attach", device_func=0x560d7a3a4ac1 <fu_plugin_device_attach>, error=0x7ffc57a51040) at ../src/fu-plugin.c:1049
4 0x0000560d7a3a618d in fu_plugin_runner_update_attach (self=0x560d7b57e160 [FuPlugin], device=0x560d7b5c4520 [FuColorhugDevice], error=0x7ffc57a51040) at ../src/fu-plugin.c:1333
5 0x0000560d7a3bcc33 in fu_engine_update
(self=0x560d7b4b9830 [FuEngine], device_id=0x560d7b64f200 "d45c9d222f7eeb3987c6a7674478bc6aec127b3f", blob_fw2=0x560d7b62c0d0, flags=FWUPD_INSTALL_FLAG_NONE, error=0x7ffc57a51150)
at ../src/fu-engine.c:2001
(gdb) print error_local
$1 = (GError_autoptr) 0x0
```
