in ee2e2c3674 the plugin name was changed
from uefi to uefi_capsule. while the config file name was changed, the
section name should also be changed.
fixes#2748
The end year is legally and functionally redundant, and more importantly causes
cherry-pick conflicts when trying to maintain old branches. Use git for history.
That giant uint64_t isn't looking so big now, and we'll want to add even more
to it in the future. Split out some private flags that are never useful to the
client, although the #defines will have to remain until we break API again.
This logic error wasn't being caught because the `DelayedActivation`
sysfs code wasn't running.
Basically the WD19TB device will have `skips-restart` applied by the quirk
by default. After `fu_thunderbolt_device_setup_controller` has run
it will have `skips-restart` removed but `usable-during-update` applied
if on a new enough kernel.
In this circumstance the `DelayedActivation` would re-apply `skips-restart`
which is the wrong intended behavior per 834b28009d
Asking the user for the UID mapping isn't working very well, as it requires lots
of manual handholding. It also doesn't work very well when the device vendor
does not actually have a PCI ID or if the vendor has split into two entities.
Just use the OUI address as an additional VendorID and match any of the device
IDs against any of the metadata-supplied values.
The fprint daemon only keeps the device open for 5 seconds and then releases it,
which seems like a small window to hit.
But! We're asking the user to authenticate with the same device we're about to
upgrade so a different part of the stack woke up the hardware just before we're
about to deploy an update onto it.
Just retry a few times to make sure the device is idle. Use a flag to prevent
accidentally causing regressions in other plugins.
Fixes https://github.com/fwupd/fwupd/issues/2650
For fuzzing we want to exclude libcurl support as it depends on other very heavy
libraries like OpenSSL or libtasn which make the fuzzing binary much larger if
linked statically.
This is probably a case where the device does not adhere to the specification.
Some hardware may be deliberately setting DNLOAD timeout to 0ms, and this patch
will make each request 5ms slower. This is probably a good tradeoff for having
most hardware 'just work' without a quirk entry.
Based on a patch by Zack Lee Yi Wei <zack_lee@chicony.com>, many thanks.
This has better multi-core performance and can run in persistent mode -- which
allows us to construct a test harness of all the parsers (which takes time) and
then just reuse the process for lots of different data.
These are expected to be flashed via UEFI capsules *not* Thunderbolt plugin
* Flashing via fwupd will require matching kernel work.
* They're left here only for parsing the binaries
```
FuThunderboltFirmwareUpdate:
Family: Maple Ridge
IsHost: true
IsNative: true
DeviceId: 0x1136
VendorId: 0xd4
ModelId: 0xa58
FlashSize: 0x0
Generation: 0x4
Ports: 0x2
HasPd: true
Section0: 0x4000
Section1: 0x4210
Section2: 0x4610
Section3: 0x22958
FuFirmwareImage:
Data: 0x67000
```
This is a safer version of g_bytes_new_from_bytes() which returns a GError
if the offsets are invalid rather than emitting a critical warning.
This prevents a critical warning and potential crash when parsing invalid
bcm57xx firmware.
Some vendors really really want 1.5.x in newer RHEL versions, but the version
of curl is too old. Add #ifdefs so that we can emulate (somewhat imperfectly)
the 'new' CURLU functonality.
I'm finally getting around to figuring out why I get occasional hard hangs after changing from a spidle to SSD. I've disabled fwupd in the meantime to see if it makes a difference. Adding the info since I don't see it already on the list.
The plugin currently supports Fastboot and QMI/PDC methods, but given
that QMI/PDC is exclusively used for carrier config installations,
there is no need for QMI/PDC-only updates, so make sure that
combination is right away forbidden.
This validation will also be useful when adding additional update
methods, as we'll be able to clearly specify which are the
combinations expcted.
The upgrade process requires that the USB interface layout is not
changed between upgrades, something that we require for AT and we also
require now for QMI. We store the USB interface number of the QMI port
as soon as the device is probed, and we use it to match the interface
number once the Udev based device is created.
squash! modem-manager: make sure the correct interface number is used for QMI
The built-in udev monitoring in the ModemManager plugin is only
required for those upgrade methods where the device switches into a
fully different port/interface layout. So far, we only expect this to
happen when the Fastboot update method is requested by the module.
The GUdevClient is created when the ModemManager sysfs path is
inhibited; we need to make sure we destroy the object once
uninhibited, or we'll otherwise create a new one if we're running
an additional upgrade operation afterwards.
This reverts commit b5eddee5f6.
Using pci function 0 works on my Lenovo P50 but not my Lenovo X1. Don't break
machines where we are shipping the chip rather than ones where we probably are
not, especially when it's probably a kernel bug somewhere.
Fixes https://github.com/fwupd/fwupd/issues/2608
The former drags on glib-networking and then gsettings-desktop-schemas, which
add over 5Mb to the minimal IoT and CoreOS composes. Everything already uses
libcurl (even NetworkManager!) and so this is an easy way to reduce image size.
We don't have to do this since we started counting the composite devices out
and back in, and relying on the parent being set at a specific instance seems
fragile in real-world testing.
Per discussion of #2513, Ubuntu Core was going to use UEFI removable
path as default esp path, and it needs to change some parts around
getting the esp path and searching the shim app path. Also, a new option
"FallbacktoRemovablePath" is added into uefi.conf to be applied in this
case, and it will be false by default.
On failure, you get this:
no device found on drm_dp_aux5: Memory query failed: failed to write command
failed to get device after update: failed to wait for detach replug
This is not complete enough for LVFS-usage, but good enough to use with commands
such as fwupdtool. It's likely newer kbd and tp firmware will be required to
integrate with the fwupd in all required ways.
The PCI Vendor and Device ID locations located in firmware were mistakenly
swapped in the bcm5719-fw repository. As a result, the code here based on said
repository also has swapped IDs. This fixes the ids to reflect the
correct locations.
Signed-off-by: Evan Lojewski <github@meklort.com>
Before:
Information for the update status entry 0:
Information Version: 7
Firmware GUID: {ddc0ee61-e7f0-4e7d-acc5-c070a398838e}
Capsule Flags: 0x00000000x
Hardware Instance: 0
Update Status: attempted
Capsule File Path: /EFI/fedora/fw/fwupd-ddc0ee61-e7f0-4e7d-acc5-c070a398838e.cap
failed: Error opening file /sys/firmware/efi/efivars/fwupd-671d19d0-43c-
4852-98d9-1ce16f9967e4-0-0abba7dc-e516-4167-bbf5-4d9d1c739416: No such file
or directory
failed: Error opening file /sys/firmware/efi/efivars/fwupd-a9971959-9246-
4a5b-b2f2-ba6fdcb19349-0-0abba7dc-e516-4167-bbf5-4d9d1c739416: No such file
or directory
After:
Information for the update status entry 0:
Information Version: 7
Firmware GUID: {ddc0ee61-e7f0-4e7d-acc5-c070a398838e}
Capsule Flags: 0x00000000x
Hardware Instance: 0
Update Status: attempted
Capsule File Path: /EFI/fedora/fw/fwupd-ddc0ee61-e7f0-4e7d-acc5-c070a398838e.cap
Information for the update status entry 1:
Firmware GUID: {671d19d0-d43c-4852-98d9-1ce16f9967e4}
Update Status: No update info found
Information for the update status entry 2:
Firmware GUID: {a9971959-9246-4a5b-b2f2-ba6fdcb19349}
Update Status: No update info found
Fixes https://github.com/fwupd/fwupd/issues/2530
Although hotpluggging PCIe cards isn't common, it's how I'm testing this in the
device test enclosure. Add a tiny delay to wait for the kernel to populate the
net class on hotplug.
Unconditionally delete FWUPDATE_VERBOSE and FWUPDATE_DEBUG_LOG when deploying
the update using fwupdtool or fwupd and leave it to fwupdate.
If you want to debug the efi binary you then have to use fwupdate and squirt
the .cap file rather than using all the other layers.
Upon restarting the upstream VLI USB hub the cxaudio device re-enumerated okay
but would not service HID requests for 100ms, returning 'endpoint stalled'.
To make this more reliable retry the SetRequest up to 10 times after a short
delay to make enumeration reliable.
The GLib g_byte_array_set_size() function does not zero the contents if the
array size is larger, which leads to unpredictable output when using valgrind.
To do this without rebooting the device implement VliUsbhubPdDevice->reload()
like the other FuVliUsbhubDevice child devices.
Fixes half of https://github.com/fwupd/fwupd/issues/2376
For instance, we can tell the user that UEFI UpdateCapsule is disabled in the
system firmware, or that efivarfs is not mounted. This is much better than
creating "dummy" devices which are really just hacks around the problem because
no better API existed. THe dummy devices cause as many problems as they solve.
Plugins have to set FWUPD_PLUGIN_FLAG_USER_WARNING if a warning should be shown
to the user, and only one warning will be shown of each failure type.
It is expected that GUI clients like gnome-software and gnome-firmware would use
this API to notify the user the localized message for why firmware updates are
not being shown.
Fixes https://github.com/fwupd/fwupd/issues/2456
Add quirks for PID 5048 and 5049, which are cros-ec devices
that update via USB endpoint. Notable about these two are
they support rw_sig, for RW region signature verification.
Our update flow prior to this was:
1. On detach, reboot to RO.
2. From Old RO, Update RW.
3. Reboot to New RW
4. From New RW, Update RO.
5. Reboot to finish
This flow has a flaw, which is that the Old RO may be buggy (especially
during development, before it's actually locked down and actually Read-Only).
This change will do the following instead:
1. On detach, do not reboot to RO if RO is writeable, and we are in RW
2. From old RW, Update RO
3. Reboot to new RO
4. From New RO, update RW
5. Reboot to finish.
This has a speed advantage as well, as we save one reboot cycle (2 vs 3).
As a result of the previous change, where we send an immediate reset to
devices in order to transition back to rw, we will end up reenumerating
as RO briefly, although the destination we wanted to get to was RW.
In that case, basically skip the write firmware step, set another write
required and allow the RO firmware to complete rw_sig and jump to the rw
partition.
Previously, we sent a 'stay-in-ro' subcommand when we are in
fu_cros_ec_usb_device_reset_to_ro, which is called from the detach phase,
in other words, we are currently sitting in RW.
This is incorrect, since stay-in-ro only interrupts an RO's
rw_sig process if it is in progress.
Instead, 'stay-in-ro' must be issued when the device reenumerates in RO,
immediately before the writing sequence starts. On devices that implement
rw_sig, they will briefly enumerate as RO before self-issuing a jump to RW
on the signature check being valid. In order to stay in RO to perform a RW
partition update, we must interrupt it as soon as we see the RO version
enumerate.
- Use pci function 0 instead of 1 when flashing firmware.
In certain situations, the BCM5719 NVM controller can lockup if
a function other than 0 is used to read from NVM word-by-word like
the kernel driver does.
- Fix APE_MODE offset in BAR[2] to enable proper resetting of the APE.
- Remove unnededed NVRam lock when resetting the APE.
Signed-off-by: Evan Lojewski <github@meklort.com>
1. Check FW in bootloader mode, need send reset command to firmware.
2. IAP Type register parameter is defind as how many bytes/page to be written.
3. Write IAP Type function in detach function.
4. Remove IAP Type function in setup function.
5. Modify page format for i2c-device
6. Modify firmware bin file size.
7. Modify firmware update flow when the firmware in bootloader mode.
8. Add another instance ID which corresponds to the IC type & module ID
* `ELANTP\ICTYPE_09&MOD_1234`
9. Add Lenovo ThinkPad X1 nano gen1 to elantp.quick
10. Add recovry device - lenovo thinkpad x1 nanao gen 1
11. Add elan touchpad device - vid:04f3 pid:314f
12. Set the firmware version when the firmware is incorrect.
Setting the default to number unconditionally causes problems when the device
is created using _register_proxy_device().
Based on a patch by Mario Limonciello <mario.limonciello@dell.com>, many thanks.
When support for dynamically mounting disks was added for 25ba41579f
udisks2 became a harder dependency and it was less obvious to users.
Create devices but show an error in why devices aren't updatable if
it's not found.
Users can still configure ESP manually in `uefi.conf`
Fixes: #2444
The FWUPD_INSTALL_FLAG_FORCE flag has really unclear semantics, and ignoring a
file CRC, checksum or model ID should only be done when using fwupdtool actually
debugging a plugin or firmware parser.
Use the existing --force flag when we want a "gentle nudge" like reuploading
previously processed reports.
This allows us to handle this in the plugin, which might mean detaching the
*proxy* device. It's also very important as a few plugins reboot the device
in ->attach() to get the new firmware version, which isn't required for a dump.
This partially reverts a58510b246 and does the
detach and attach in the few plugins where actually required.
With how well fwupd UEFI updates work these days >99% of people
don't need to see messages about the capsule update running.
Those who have problems, this isn't going to help them.
Firsly, that HSI isn't expected for embedded devices and then secondary how we
require SecureBoot to be available for HSI:1
At the moment we get a runtime failure if it is disabled. Making SB a part of
`HSI:1` makes this requiremnt explicit and prevents us getting `HSI:2!` if it
is not available.
The 721C is a VL103, which isn't a FuVliUsbhubDevice at all. Fixes the:
already set GType to FuVliPdDevice, ignoring FuVliUsbhubDevice
...message when the Mini dock / powered hub is inserted.
Use one of the errors mapping to FWUPD_UPDATE_STATE_FAILED_TRANSIENT to avoid
uploading a failure report for something the user has to fix, i.e. update the
distro shim package.
Conceptually we were trying to stuff subtly different actions into one vfunc:
* Read firmware from the device to update the verification checksums
* Read a firmware blob from the device for debugging
For the first action we might want to mask out the sections of the flash with
serial numbers (so the verification hashes match the ones published on the LVFS)
and for the second we want just a raw ROM file from the hardware with no
pre-processing that we can compare against an external SPI dumper.
Split out ->dump_firmware to get the raw blob, and allow plugins to also
implement ->read_firmware() if they have to mask out specific offsets or remove
specific images from the FuFirmware container.
In the common case when masking is not required, fall back to using a 'binary'
FuFirmware automatically to make most plugins simpler.
At the moment there are commands to convert one file format to another, but not
to 'merge' or alter them. Some firmware files are containers which can store
multiple images, each with optional id, idx and addresses.
This would allow us to, for instance, create a DfuSe file with two different
raw files that are flashed to different addresses on the SPI flash. It would
also allow us to create very small complicated container formats for fuzzing.
This can be used by writing a `firmware.builder.xml` file like:
<?xml version="1.0" encoding="UTF-8"?>
<firmware gtype="FuBcm57xxFirmware">
<version>1.2.3</version>
<image>
<version>4.5.6</version>
<id>header</id>
<idx>456</idx>
<addr>0x456</addr>
<filename>header.bin</filename>
</image>
<image>
<version>7.8.9</version>
<id>payload</id>
<idx>789</idx>
<addr>0x789</addr>
<data>aGVsbG8=</data>
</image>
</firmware>
...and then using something like:
# fwupdtool firmware-convert firmware.builder.xml firmware.dfu builder dfu
This is only applicable for kernel 5.9 or kernels that backported
the authenticate on disconnect patches.
For installation time this isn't very important since no device will
restart. This also isn't relevant for the authenticate on disconnect
scenario.
However the manual activation scenario, it's important to activate the
WD19TB device first, followed by Thunderbolt.
I2C doesn't have any specification for what is a probe and what is a more
destructive action. Sending tx_buf out on the i2c bus to a generic address
might not be safe in all cases.
To prevent this, use a HWID to check the machine DMI value during device
creation before ->probe() or ->setup() is called on the device.
If the device is not authorized, it may cause a composite update that it's part
of to not behave properly.
If device is authorized at runtime, add updatable flag at runtime as well
See #2374 for more details
This ensures we perform the updates in this order:
* cxaudio
* vli
* thunderbolt
As any other order causes enumeration failures.
Fixes some of https://github.com/fwupd/fwupd/issues/2377
Error will show up if (priv->physical_id == NULL) on
fu_device_ensure_id(). This method is called after probe but before
setup on fu_device_open.
Call fu_device_set_physical_id() on fu_thunderbolt_device_probe()
for the retimer case.
Fixes https://github.com/fwupd/fwupd/issues/2371
Change-Id: I0e462fff5e8abf6073318f6424b6736afc8259b8
This object derives from FuDevice rather than FuVliDevice and so does not
inherit the NO_GUID_MATCHING flag like other devices.
Fixes https://github.com/fwupd/fwupd/issues/2364
It seems the MEI parameters are not set for platforms such as Apollo Lake.
The only bit set was FPF_SOC_LOCK, with the others all cleared to zero.
Fixes https://github.com/fwupd/fwupd/issues/2335 for a peculiar definition of 'fix'.
As described in DFU protocol (7. Manifestation Phase), after the
firmware reprogramming is done, if bitWillDetach = 1, it doesn't
require the host to issue a USB bus reset, but the device can
generate a detach-attach sequence itself to go back to normal.
Add a quirk flag "no-bus-reset-attach" to skip the bus reset in
dfu_device_attach(), and increase the "RemoveDelay" as well.
Print the sysfs path for devices deriving from FuUdevDevice, which also allows
us to use FU_UDEV_DEVICE_DEBUG without monkey-patching the plugins that also
define a device_class->to_string() vfunc.
For some Poly USB Cameras, it takes a longer time than the
default (FU_DEVICE_REMOVE_DELAY_RE_ENUMERATE) for being detached
to DFU or attached to normal mode. Need to specify the timeout in
"RemoveDelay" quirk key.
Also replace the hard-coded timeout with fu_device_get_remove_delay()
in dfu-tool.c.
Some devices may accumulate the firmware image and perform the
entire reprogramming operation at one time. In this case, the
device enters dfuMANIFEST-SYNC or dfuMANIFEST state after
dfuDNLOAD-IDLE.
The fwupd shall be able to poll the status from the device via
DFU_GETSTATUS until the device completes the reprogramming or
reports an error.
For details, please refer to Section 7. Manifestation Phase and
A.1 Interface State Transition Diagram in the USB DFU protocol.
https://www.usb.org/sites/default/files/DFU_1.1.pdf
For not affecting the other DFU capable devices, introduce a quirk
"manifest-poll" to limit the logic.
The nr_chunks is defined as an unsigned short, the max value is
65536. Assume the transfer_size reported by device is 4096, the
maximum size of DFU firmware supported is 65536 * 4096 = 256MB.
To support larger DFU firmware, we can change the guint16 to
guint32.
This implements the following simple state machine:
1. Reboot to RO, Update RW first, set ANOTHER_WRITE_REQUIRED
2. Second time around, don't reboot into RO. Stay in RW.
3. Update RO.
4. Done.
Only add instance ID if it actually probes properly.
Otherwise this makes an invalid assumption that the device is a WD19
EC just because it had the correct hub in front.
Instead check the first time it's opened that the correct device
is identified (`EXPECTED_DOCK_TYPE`)
This is much more efficient than parsing hundreds of lines of /proc/cpuinfo
and also causes hundreds of thousands less allocations at startup. For systems
with dozens of virtual CPUs the deduplication of device objects was increasing
start up time considerably.
Use the msr plugin to read the microcode version as this is not obtained using
CPUID, as it is instead being provided in an MSR.
To do this mount all ESP partitions and check all the binaries there to see if
they match any entries in the new dbx. If we applied the update when a hash
matched, we would unintentially 'brick' the users machine, as the grub and shim
binaries *have* to be updated first.
This functionality does reimplement the PE hashing functionality found in
sbsigntools and pesign. This was done for 4 main reasons:
* There were some memory safety issues found when fuzzing random binaries
* Executing the tools hundreds of times was a lot of overhead
* Operating from a blob of immutable mmap'd memory is much faster
* We only need a very small amount of functionality from both tools
