This allows us to show in the tools if a device is currently affected
by a specific CVE. For instance, we could inform the user that a device
requires a critical firmware update that is being actively exploited.
Note, this also means we can show the user a firmware update is now
required, even though the firmware may not be available on the LVFS.
Also show the issue in the `fwupdmgr security` output, e.g.
There are devices with issues:
Samsung — MZVLB2T0HALB-000L7:
• CVE-2022-12345
• CVE-2022-54321
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
This change offline ports in the host controller
for retimers to enumerate in the NDA case.
-offline and rescan usb4 ports
-this enable enumeration of the retimers
-updates nvm to the enumerated retimers
-online usb4 port this will de-enumerate retimers
BUG=b:187506425
TEST=emerge-volteer fwupd
Signed-off-by: Kranthi Kuntala <kranthi.kuntala@intel.corp-partner.google.com>
Quite a few plugins are using a FuDeviceLocker to detach then attach in
the error path, and finding them isn't easy as we explicitly cast to a
FuDeviceLockerFunc.
For sanity, just provide both symbols so we can do the right thing in
both cases. It seems like a sensible thing to allow.
Fixes https://github.com/fwupd/fwupd/issues/3771
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.
The benefit of using the proxy device is that we can 'use' the proxy
device for device access, but 'report' the progress on the passed
FuDevice instance.
This means the front-end reports the device status correctly when
updating composite devices that us proxies.
The comment always said we should move it to the daemon if another
plugin started doing this, and that is now.
The "return error and hope the client resubmits the firmware again"
pattern is clunky. There are two plugins doing this now, and about to
be one more.
This adds FwupdRequest which provides a structured way of asking the
user to perform an action, e.g. to replug the device or to press a
special key or button.
This replaces much of the UpdateMessage and UpdateImage API although
it is still used internally. Clients capable of processing the new
DeviceRequest signal should add REQUESTS to their feature flags.
Also, this allows us go back to the old meaning of _NEEDS_BOOTLOADER,
which was "needs rebooting into a bootloader mode" rather than the
slightly weird "user needs to do something and resubmit request".
At the moment the device list auto-removes children when the parent is
removed. This was originally working around the bug that the child
devices had no backend ID, and thus were not matched like the parent
in fu_engine_backend_device_removed_cb() and removed automatically.
Using the workaround means that the children are potentially removed
before the parent depending on the order of the device list -- which
might be modified by replug events.
I think the old cleanup is probably an anti-pattern, and going forward
composite devices should probably define _NO_AUTO_REMOVE_CHILDREN but
we don't want to change this behaviour for plugins already expecting
the old flow, or for devices with no parent backend IDs.
If adding an entry into the class function table then the padding has
to be decremented unless the SO version is incremented.
Fixes out-of-tree plugins failing to load with:
GLib-GObject: Specified class size for type 'FuXxxDevice' is smaller
than the parent type's 'FuDevice' class size
This means we don't display something like 'Logitech Logitech Product'
when showing the devices on one line.
This is now required in two plugins so move it to common code. Also
support setting the properties in either order to prevent regressions
when using the device name as part of the instance ID.
The CustomFlags feature is a bit of a hack where we just join the flags
and store in the device metadata section as a string. This makes it
inefficient to check if just one flag exists as we have to split the
string to a temporary array each time.
Rather than adding to the hack by splitting, appending (if not exists)
then joining again, store the flags in the plugin privdata directly.
This allows us to support negating custom properties (e.g. ~hint) and
also allows quirks to append custom values without duplicating them on
each GUID match, e.g.
[USB\VID_17EF&PID_307F]
Plugin = customflag1
[USB\VID_17EF&PID_307F&HUB_0002]
Flags = customflag2
...would result in customflag1,customflag2 which is the same as you'd
get from an enumerated device flag doing the same thing.
Add a FuDevice->ready() vfunc that is run after ->setup()
This allows plugins to perform setup actions that require quirk matches
after the instance IDs have been converted. This allows us to also
remove FuVliDevice->setup() as the ordering chain has been broken.
There are two USB-3 hubs internally (with the same VID&PID), and the
MSP430 is only attached to the top-level one.
Fixes https://github.com/fwupd/fwupd/issues/3366
The activation flag is stored into the history database, but not all
plugins will want to inherit it on coldplug the next time the daemon
is started.
For example the Dell Dock plugin will query this information from the
device and it will prevent getting into a bad state as a result.
Fixes: #3106
There is a lot of code in fwupd that just assigns a shared object type to
a FuPlugin, and then for each device on that plugin assigns that same shared
object to each FuDevice.
Rather than proxy several kinds of information stores over two different levels
of abstraction create a 'context' which contains the shared *system* state
between the daemon, the plugins and the daemon.
This will allow us to hold other per-machine state in the future, for instance
the system battery level or AC state.
We already have two things managing the UPDATABLE_HIDDEN->UPDATABLE transition,
and we're about to add a third.
Add a 'stackable' inhibit-style API so we do not accidentally mark a device as
updatable when it should remain hidden.
Keeping *internal* API and ABI compatibility makes working with an already
complex codebase more mentally demanding than it needs to be.
Remember: plugins should be in-tree and upstream! If your out of tree plugin
stops working then it should be upstream.
The public-facing libfwupd will remain API and ABI stable for obvious reasons.
We want to make it as easy as possible for devices to refuse to update on low
battery, as this will likely be one of the WWCB requirements.
Ideally devices will check the battery level inside the firmware, but by also
providing the battery level to fwupd we can give the user a warning *before*
the update has started and without switching the device into bootloader mode.
Devices may want to support more than one protocol, and for some devices
(e.g. Unifying peripherals stuck in bootloader mode) you might not even be able
to query for the correct protocol anyway.
It is far too easy to forget to set FWUPD_DEVICE_FLAG_NO_GUID_MATCHING for new
plugins, and without it it all works really well *until* a user has two devices
of the same type installed at the same time and then one 'disappears' for hard
to explain reasons. Typically we only need it for replug anyway!
Explicitly opt-in to this rarely-required behaviour, with the default to just
use the physical and logical IDs. Also document the update behavior for each
plugin to explain why the flag is being used.
This allows you to have two identical Unifying plugged in without one of them
being hidden from the user, at the same time allowing a HIDRAW<->USB transition
when going to and from bootloader and runtime modes.
This removes the workaround added in 99eb3f06b6.
Fixes https://github.com/fwupd/fwupd/issues/2915
This is typically a Linux sysfs path or USB platform ID and is used in a
different way to the physical ID. The physical ID is only set for some devices
after setup() and depends on the subsystem list, and this would not be defined
for devices that do not match a plugin.
This also fixes an regression where the FuDeviceList fails to match the new
FuUdevDevice device in fu_device_list_get_by_guids_removed() and instead
silently gets 'fixed up' only if FWUPD_DEVICE_FLAG_NO_GUID_MATCHING is not set.
This also allows us to move the various backends device caches to FuBackend as
we now have a suitable ID that is for just the backend to use.
