The daemon creates a baseclass of either FuUsbDevice or FuUdevDevice when the
devices are added or coldplugged to match the quirk database and to find out
what plugin to run.
This is proxied to plugins, but they are given the GUsbDevice or GUdevDevice and
the FuDevice is just thrown away. Most plugins either use a FuUsbDevice or
superclassed version like FuNvmeDevice and so we re-create the FuDevice, re-probe
the hardware, re-query the quirk database and then return this to the daemon.
In some cases, plugins actually probe the hardware three times (!) by creating
a FuUsbDevice to get the quirks, so that the plugin knows what kind of
superclass to create, which then itself probes the hardware again.
Passing the temporary FuDevice to the plugins means that the simplest ones can
just fu_plugin_device_add() the passed in object, or create a superclass and
incorporate the actual GUsbDevice and all the GUIDs.
This breaks internal plugin API but speeds up startup substantially and deletes
a lot of code.
If another plugin causes a Synaptics MST device to be removed, it
also needs to be removed from the cache to prevent problems when
the device is re-probed.
1) Switch to daemon provided vfuncs for USB
2) Set quirks so that the plugin only runs when Realtek NIC shows up
3) Rely on the daemon to process all removals by parent tree
The setup() is the counterpart to probe(), the difference being the former needs
the device open and the latter does not.
This allows objects that derive from FuDevice, and use FuDeviceLocker to use
open() and close() without worrying about the performance implications of
probing the hardware, i.e. open() now simply opens a file or device.
These are GUIDs that are related to the main device, but should not be used for
quirk matching. For instance, we might want to list the GUIDs for a bootloader
mode, but we don't want to import all the quirks for the bootloader when in the
runtime mode.
This flag is intended for devices that the restart procedure will
be performed as part of a transactional update by an external
controller.
None of the currently supported devices need this flag.
This allows us to match non-DeviceID GUIDs, and also GUIDs we don't know how to
generate.
To make this fully useful, search for device quirks when GUIDs are added.
This was compiling and passing CI as the un-implemented legacy functionality
was still exported in the header.
Remove the prototypes for the missing symbols and fix up the plugin.
Apparently the linker complains when dlopen'ing a plugin that's linked against
the libfwupdprivate library the daemon is using. This only seems to happen when
using distro packages...
The size check would always short circuit as
FU_WAC_DEVICE_FEATURE_FLAG_ALLOW_TRUNC == 0
is never true. The error message was thus never
written even if a difference was found.
With this patch we check if ALLOW_TRUNC is set in flags
instead, and only write the error if it is not.
Five plugins (soon to be 7) are linking to the DFU plugin just for this simple
segment-aware chunking functionality. Move this into common code to make
building simpler.
systemd-automount will unmount the ESP when not in use for some
people. This causes automatic ESP detection to fail.
In this case the ESP will need to be added to the conf file and
then this commit will let it keep working.
Currently we only parse the nvm_version attribute according fwupd
expectations when the device is initially added. Elsewhere we just use
the raw version as is which might be problematic as the version format
can change in the middle (for example "33.02" vs. "33.2"). Fix this so
that fu_plugin_thunderbolt_udev_get_version () always returns parsed
version string.
Update self tests accordingly to have "parsed" version to which we
compare against.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Since the multi controller entry is part of the DROM and its place is
not fixed, it is possible (however unlikely) that the locations between
controller and the image are different. One scenario is that the new
image has typo in device or vendor name string fixed which could cause
the offset to be different.
To handle this case properly we need to read multi controller locations
of both controller and image separately, read their values and then
compare them against each other.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
During review it was pointed out that the return value of
read_drom_entry_location () should be documented because it also returns
TRUE when an entry was not found from the DROM. Caller needs to look for
the location->offset in that case. Add a comment explaining this.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Alpine Ridge and Alpine Ridge LP also include flash size field so follow
Titan Ridge and validate those as well.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
This reverts commit ed7acc7819.
As pointed out by @YehezkelShB during review the Titan Ridge IDs 0x15E8
and 0x15EB are for the NHI (the host controller). Windows SDK tool uses
them to keep track of different controllers but in Linux we don't need
them and can use the already existing bridge IDs.
There is no harm to have them listed but to avoid possible confusion in
future remove them.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
/boot is a special cased directory when using ProtectSystem=full
Due to this, it's marked read only even if it's listed in ReadWritePaths.
Allow folks to use this for their ESP, but they need to create /boot/EFI
in advance of starting fwupd.
Titan Ridge devices may contain multiple controllers so we need to make
sure the supplied NVM image multi controller number matches the
controller in question. This is pretty much same than we had for Alpine
Ridge (X of N) but the difference is that this multi controller
information is found in DROM instead and the location is not fixed.
For this reason we implement a generic DROM entry parser and use it to
dynamically fill in correct location of multi controller entry based on
the controller active firmware.
In addition to that we add a check for the NVM flash size just like we
do for Titan Ridge host.
Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@intel.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Titan Ridge has same set of bits than Alpine Ridge telling whether the
Thunderbolt controller is in native or legacy mode. Add validation for
that.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
We need to make sure the Thunderbolt controller and the NVM image agree
with the expected flash memory size.
Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@intel.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Add 0x15E8 and 0x15EB Titan Ridge IDs that were previously missed.
Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@intel.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Thunderbolt devices typically have a discrete PD (power delivery)
controller and firmware for that controller is part of the NVM image. To
make sure the supplied NVM image provides the necessary PD firmware we
implement a check that compares existence of both PD pointers and fails
the validation if they differ.
Since the PD pointer is part of ARC_PARAMS section we need to populate
that section offset also for hosts (following DROM section).
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
At least with Titan Ridge devices 50 * 20 ms is way too short time
reading nvm_version so most of the time the daemon fails to figure out
the version of the just connected device. To make it work better with
Titan Ridge devices increase the timeout to 50 * 200 ms.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
There are other places in the plugin where we read nvm_version and it
can return -EAGAIN as well. To make sure it works consistenly accross
the plugin factor reading nvm_version to a helper function and use instead.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Additionally, if the user specified something invalid, do not autodetect the
ESP but return with a journal error. It seems wrong to ignore what the user
explicitly set and perhaps do something dangerous.
Alternative to https://github.com/hughsie/fwupd/pull/599
Panamera is a newer MST chip with a different flash layout and
multiple MCU running and accessing SPI/EEPROM simultaneously.
The firmware update process has to be run separately for each
SPI/EEPROM region.
Signed-off-by: Ryan Chang <ryan.chang@synaptics.com>
Signed-off-by: Mario Limonciello <mario.limonciello@dell.com>
- Split up `synapticsmst_device_write_firmware` to smaller more manageable
chunks
- Use `FuDeviceLocker` to ensure that device is in a known state after
update is complete (both in success or failure scenarios)
- Retry the write process up to 10 times in case of DPCD update failures
- Wait for flash clear to settle before writing to EEPROM/SPI
Any previously failed runs or outside tools may adjust the remote
control register leaving the MST controller in a poor state.
If remote control enablement fails, try to disable and then re-enable
before aborting.
As seen by recent testing this is not working every time.
Since e6cda81f we're now building GUIDs that represent all the possibilities
for shared parts so it's not important to set dock type.
Since the Redfish service may use a self-signed certificate without
specifying the hostname, we could have the problem to verify such
certificate. A new option, CACheck, is introduced so that the user can
decide whether to ignore the CA verification or not.
Signed-off-by: Gary Lin <glin@suse.com>
This commit adds redfish.conf to configure the IP and username/password
in case those are not available in SMBIOS and the EFI variables.
Since we can configure the IP in the conf file, the environment
variable, FWUPD_REDFISH_URI, is removed.
Signed-off-by: Gary Lin <glin@suse.com>
Although SoupAuthManager can create a proper SoupAuth from the
WWW-Authenticate header, some redfish implementations didn't provide
such header, and we would get a 401 response in the end.
In DSP0266, it mentions that "HTTP BASIC authentication as defined by
RFC7235 shall be supported", so it shall be safe to use Basic Auth
by default.
Signed-off-by: Gary Lin <glin@suse.com>
DeviceClass in Oem/Hpe indicates the type of device in the HPE machine.
In case SoftwareId is absent, we can use DeviceClass instead.
Signed-off-by: Gary Lin <glin@suse.com>
Although "Updateable" is defined in SoftwareInventory schema since
redfish v1.0.0, some machines(*) didn't support the field.
"SoftwareId" is defined in SoftwareInventory schema since v1.1.0, so
it probably isn't supported by every redfish machines.
(*) Try "/redfish/v1/UpdateService/FirmwareInventory/1/" with HPE DL380
Gen 10 in https://ilorestfulapiexplorer.ext.hpe.com/
Signed-off-by: Gary Lin <glin@suse.com>
In the Members array of FirmwareInventory or SoftwareInventory, each
element of the array only contains the URI to the member. For example:
"Members":
[
{
"@odata.id": "/redfish/v1/UpdateService/FirmwareInventory/1/"
},
{
"@odata.id": "/redfish/v1/UpdateService/FirmwareInventory/2/"
},
{
"@odata.id": "/redfish/v1/UpdateService/FirmwareInventory/3/"
}
]
We have to get the real member object through the given URI.
If the dock information is available then show that in the device name
and restrict the GUIDs created.
If it's not available, then just create GUIDs for all known docks
Previously if missing secure boot binaries, or invalid ESP was created the
plugin would just not load.
Now instead populate UpdateError and remove the updateble flag, but still show
the device in fwupdmgr and fwupdtool.
1) Drop the path at the end of the title (\fwupdx64.efi)
2) Linux-Firmware-Updater to Linux Firmware Updater
The behavior that required the hacky name has been fixed since shim 10
which is in all the relevant distros now.
3322257e61
In the redfish emulator, "/redfish/v1" returns "ServiceVersion".
However, in the HPE API explorer(*), it returns "RedfishVersion".
This commit checks both member and print the one that is available.
(*) https://ilorestfulapiexplorer.ext.hpe.com/
Redfish is an open industry standard specification and schema that helps enable
simple and secure management of modern scalable platform hardware.
This has only ever been tested using an emulator and not on real hardware.
Check across a list of common EFI system partition locations for a mounted
location before starting fwupd.
This also will cause the plugin to not initialize if the EFI system partition
is not mounted.
If the user is using some super-old kernel or broken system we want to return
early with an error rather than try to catch each way this can fail at runtime.
This pivots the data storage so that the group is used as the preconditon
and the key name is used as the parameter to change. This allows a more natural
data flow, where a new device needs one new group and a few few keys, rather
than multiple groups, each with one key.
This also allows us to remove the key globbing when matching the version format
which is often a source of confusion.
Whilst changing all the quirk files, change the key prefixes to be more familiar
to Windows users (e.g. Hwid -> Smbios, and FuUsbDevice -> DeviceInstanceId)
who have to use the same IDs in Windows Update.
This also allows us to pre-match the desired plugin, rather than calling the
probe() function on each plugin.
We need to remove the flag if the quirk is not present.
Fixes the cosmetic-but-scary-looking 'failed to send to device on ep 0x01: USB
error on device 2dc8:9001 : Input/output error'.
Fixes the other half of https://github.com/hughsie/fwupd/issues/565
If the daemon either de-duplicates or replaces the object passed emitted from
device-added then the object set as the alternate may not be the same instance
as the daemon version. This causes weird things to happen.
To make this less fragile, specify the *ID* of the object that should be the
alternate device, which allows the daemon to do clever things, and then assign
the object from the ID as the last step.
Although fixing no bug, this makes implementing future functionality easier.
Get the TPM v2.0 and v1.2 devices explictly rather than assuming the non-alt
device is always added first. This has the side effect of making the tests
easier to read and means we can check the dock components more carefully.
Requiring colord to be built before fwupd makes it hard to build packages.
The HID-based flashing protocol is stable and documented, so there's no need
to use an external library for this now.
Using just the default GUID is fragile and might break if the GUIDs get added
in the 'wrong' order or if the GUID list is sorted.
Fixes https://github.com/hughsie/fwupd/issues/518
Several places in the UEFI plugin operate on the default GUID rather
than iterating a list of GUIDs. This is normally fine since UEFI
GUIDs are tied to the ESRT and normally one FuDevice shouldn't
have multiple GUIDs.
The alternate GUID was added to set parents accordingly but this
caused no CAB files to be able to install.
Fixes: cc664d7d (amt: Put the AMT device as a child under the system UEFI firmware)
../plugins/amt/fu-plugin-amt.c: In function ‘mei_context_new’:
../plugins/amt/fu-plugin-amt.c:77:2: error: implicit declaration of function ‘memcpy’ [-Werror=implicit-function-declaration]
memcpy (&ctx->guid, guid, sizeof(*guid));
^~~~~~
../plugins/amt/fu-plugin-amt.c:77:2: error: incompatible implicit declaration of built-in function ‘memcpy’ [-Werror]
../plugins/amt/fu-plugin-amt.c:77:2: note: include ‘<string.h>’ or provide a declaration of ‘memcpy’
../plugins/amt/fu-plugin-amt.c:78:2: error: implicit declaration of function ‘memset’ [-Werror=implicit-function-declaration]
memset (&data, 0, sizeof(data));
^~~~~~
../plugins/amt/fu-plugin-amt.c:78:2: error: incompatible implicit declaration of built-in function ‘memset’ [-Werror]
../plugins/amt/fu-plugin-amt.c:78:2: note: include ‘<string.h>’ or provide a declaration of ‘memset’
../plugins/amt/fu-plugin-amt.c: In function ‘mei_recv_msg’:
../plugins/amt/fu-plugin-amt.c:117:9: error: implicit declaration of function ‘strerror’; did you mean ‘g_strerror’? [-Werror=implicit-function-declaration]
rc, strerror(errno));
^~~~~~~~
g_strerror
../plugins/amt/fu-plugin-amt.c:117:9: error: nested extern declaration of ‘strerror’ [-Werror=nested-externs]
../plugins/amt/fu-plugin-amt.c:116:39: error: format ‘%s’ expects argument of type ‘char *’, but argument 6 has type ‘int’ [-Werror=format=]
"read failed with status %zd %s",
~^
%d
rc, strerror(errno));
~~~~~~~~~~~~~~~
../plugins/amt/fu-plugin-amt.c: In function ‘mei_send_msg’:
../plugins/amt/fu-plugin-amt.c:142:40: error: format ‘%s’ expects argument of type ‘char *’, but argument 6 has type ‘int’ [-Werror=format=]
"write failed with status %zd %s",
~^
%d
written, strerror(errno));
~~~~~~~~~~~~~~~
../plugins/amt/fu-plugin-amt.c: In function ‘amt_verify_code_versions’:
../plugins/amt/fu-plugin-amt.c:288:14: error: implicit declaration of function ‘strlen’ [-Werror=implicit-function-declaration]
len != strlen(code_ver->versions[i].version.string))
^~~~~~
../plugins/amt/fu-plugin-amt.c:288:14: error: incompatible implicit declaration of built-in function ‘strlen’ [-Werror]
../plugins/amt/fu-plugin-amt.c:288:14: note: include ‘<string.h>’ or provide a declaration of ‘strlen’
../plugins/amt/fu-plugin-amt.c: In function ‘fu_plugin_amt_create_device’:
../plugins/amt/fu-plugin-amt.c:430:2: error: incompatible implicit declaration of built-in function ‘memcpy’ [-Werror]
memcpy (&ver, response->data, sizeof(struct amt_code_versions));
^~~~~~
../plugins/amt/fu-plugin-amt.c:430:2: note: include ‘<string.h>’ or provide a declaration of ‘memcpy’
cc1: all warnings being treated as errors
This reverts commit 6b0eb07886.
Per debian bug 896012 this is intentional behavior and a problem with
linitin. An additional commit will be added to ignore this lintian
error.
This allows plugins to set and explicit build-time version. It also uses the
same AppStream component-ID scheme rather than the home-grown 'FooVersion' key.
Also, use the new runtime and compile-time versions in the report metadata.
Due to the key change we'll also need to update some LVFS rules.
In some cases firmware can only be installed with an up to date GUsb (e.g. with
some STM-DFU hardware) or with a new version of fwupdate (e.g. any UEFI
UpdateCapsule without a capsule header).
We should be able to match against other software versions like we can the
fwupd version, e.g.
<requires>
<id compare="ge" version="0.9.2">org.freedesktop.fwupd</id>
<id compare="ge" version="11">com.redhat.fwupdate</id>
</requires>
Also, rather than checking each requirement we know about on the component,
check each requirement on the component about things we know. This ensures we
don't allow firmware to be installs that requires for instance fwupdate 22 when
the runtime version is only being added in fwupdate 12 and up.
This means the following is now an error that will fail to allow the firmware
to be installed:
<requires>
<firmware>doesnotexist</firmware>
<some_future_tag>also_unknown</some_future_tag>
</requires>
Also add a lot of self tests to test the various new failure modes.
Fixes https://github.com/hughsie/fwupd/issues/463
This is a workaround for what looks like a compiler bug introduced
in Debian and Ubuntu gcc-7.
After the compiler bug is sorted in Debian testing it should be
reverted.
There are a lot of hacks here;
* Pulling newer libappstream-glib from Fedora
* Pulling a systemd backport
* Manually installing pillow and pygobject
* PKCS7 is turned off (gnutls is too old)
GLib creates two static inline functions for paramaters that may
not be used that set off warnings in clang but not gcc.
Ignore these on clang builds everywhere that
G_DEFINE_AUTOPTR_CLEANUP_FUNC is used.
A test run should really fail if it cannot find the test data, rather
then reporting success (thus masking that it never ran). Fix the test to
find it data (probably broken with the port to meson) and make it fail
if it cannot find its data.
Signed-off-by: Sjoerd Simons <sjoerd.simons@collabora.co.uk>
Rather then always assuming open() fails because of permission denied,
generate the GError code from the errno and add the related strerror to
the message. And ofcourse output the error message in debugging rather
then just ignoring it.
Signed-off-by: Sjoerd Simons <sjoerd.simons@collabora.co.uk>
If recoldplug is called in the middle of a Thunderbolt firmware update it will
cause the Thunderbolt controller to be in the wrong state and make it appear
that the controller update failed.
The type of Dell dock gets used in the device GUID, so make that
mandatory for device enumeration to succeed. Only relying on the
synapticsmst plugin to be cold plugged after the dell plugin isn't
enough to ensure this.
Signed-off-by: Sjoerd Simons <sjoerd.simons@collabora.co.uk>
When hitting a failure during enumerating make sure remote control mode
is disabled again.
Signed-off-by: Sjoerd Simons <sjoerd.simons@collabora.co.uk>
On Dell dock devices set the FU_DEVICE_METADATA_DELL_DOCK_TYPE metadata
field which gets used by the synapticsmst plugin for recognizing dell
dock types.
Signed-off-by: Sjoerd Simons <sjoerd.simons@collabora.co.uk>
A race condition is hypothesized in the following scenario:
1. User starts up the system and fwupd doesn't start automatically.
2. User manually calls fwupdmgr install blah.cab (or fwupdmgr update really) which uses dbus activation to start fwupd systemd unit.
3. This runs coldplug on thunderbolt plugin, no devices found. Thunderbolt power runs coldplug routine.
a. This sets forcepower with a timeout to turn off after 20 seconds.
b. Coldplug exits.
4. update routine starts
a. Thunderbolt plugin starts flash routine.
b. Thunderbolt power plugin turns off force power in middle of flash routine.
c. Issue described happens.
