Avoid checking if bolt supports force-power in coldplug (early on)
because that will dbus-activate boltd, even on systems where there
is no actual thunderbolt hardware and thus also no force-power
support. Since boltd does use the very same kernel mechanism that
fwupd would use when boltd is not around this can not lead to any
regressions.
There are some packaging problems in some distributions that lead
to TSS stack emitting warnings that will fail self tests.
These don't occur as root, and furthermore those distributions run
CI as root already.
And in the dell plugin make it non-fatal to have TPM register read failures
in case the system has TPM1.2 not TPM2.0
If we're using an instance ID with FU_DEVICE_INSTANCE_FLAG_ONLY_QUIRKS (e.g.
for the vendor match in the previous commit) then the GUID is not available.
When the system doesn't support UEFI capsule updates no firmware version
is displayed for the BIOS. Fix this by creating a dummy device:
```
├─System Firmware:
│ Device ID: 123fd4143619569d8ddb6ea47d1d3911eb5ef07a
│ Current version: 1.7.0
│ Vendor: Dell Inc.
│ Update Error: UEFI Capsule updates not available or enabled
│ Flags: internal|require-ac|registered|needs-reboot
```
If the dell-esrt plugin determines that capsule updates can be enabled
however, make the device it creates replace the dummy device:
```
├─Dell UEFI updates:
│ Device ID: 123fd4143619569d8ddb6ea47d1d3911eb5ef07a
│ Summary: Enable UEFI Update Functionality
│ Current version: 0
│ Update Error: Firmware updates disabled; run 'fwupdmgr unlock' to enable
│ Flags: locked|supported|registered|needs-reboot
```
Fixes: #1366
The factory-shipped MinnowBoardMAX board has firmware that does not include
the ESRT table. Create a 'fake' UEFI device with the lowest possible version
so that it can be updated to any version firmware.
All the HwId GUIDs are used for the fake UEFI device, and so should be used in
the firmware metadata for releases that should recover the system.
The fwupd UEFI plugin refuses to start if bit 3 of the "BIOS Characteristics
Extension Byte 2" (13h) is cleared. Bit 3 is UEFI Specification is supported.
Also, double-check that /sys/firmware/efi does not exist before disabling the
plugin as other machines may be affected too. The quirk then acts to supress
the console warning about the broken SMBIOS value.
Fixes https://github.com/fwupd/fwupd/issues/1342
These are a more scalable way to apply firmware across a variety of
platforms.
An example:
```
XPS 13 7390 TPM 2.0
DeviceId: c56e9f77cfee65151bdef90310776f9d62827f5a
Guid: a4352c96-f8d7-526c-8485-7f84085f348e <- 0962-2.0
Guid: 7d65b10b-bb24-552d-ade5-590b3b278188 <- DELL-TPM-2.0-NTC-NPCT
Guid: 6f5ddd3a-8339-5b2a-b9a6-cf3b92f6c86d <- DELL-TPM-2.0-NTC-NPCT75x
Guid: fe462d4a-e48f-5069-9172-47330fc5e838 <- DELL-TPM-2.0-NTC-NPCT75xrls
Summary: Platform TPM device
Plugin: uefi
Flags: internal|require-ac|registered
Vendor: Dell Inc.
Version: 7.2.1.0
VersionFormat: quad
Icon: computer
Created: 2019-09-04
```
When this system is queried using tpm2-tools:
```
$ sudo tpm2_getcap -c properties-fixed
TPM_PT_FAMILY_INDICATOR:
as UINT32: 0x08322e3000
as string: "2.0"
TPM_PT_LEVEL: 0
TPM_PT_REVISION: 1.38
TPM_PT_DAY_OF_YEAR: 0x00000008
TPM_PT_YEAR: 0x000007e2
TPM_PT_MANUFACTURER: 0x4e544300
TPM_PT_VENDOR_STRING_1:
as UINT32: 0x4e504354
as string: "NPCT"
TPM_PT_VENDOR_STRING_2:
as UINT32: 0x37357800
as string: "75x"
TPM_PT_VENDOR_STRING_3:
as UINT32: 0x02010024
as string: ""
TPM_PT_VENDOR_STRING_4:
as UINT32: 0x726c7300
as string: "rls"
```
The new firmware for receivers with the nordic chips is using the 0x04
record type. This was previously not handled when parsing the file,
causing wrong behavior when trying to update the device. This patch
tries to properly deal with the record types, being them 0x04 or other.
Signed-off-by: Filipe Laíns <lains@archlinux.org>
There are commits to the Thunderbolt kernel driver that make sure
that the upgrade process goes smoothly. If these commits aren't
present then it will look like a fwupd problem, when it's actually
a kernel problem.
When this issue was reported it appeared that commit
e4be8c9b6a
was missing from the locally tested kernel, but it's impossible
to determine that from userspace.
Prevent running the thunderbolt plugin on older kernels than that
set in `$sysconfdir/fwupd/thunderbolt.conf`.
By default that is set to 4.13.0, but if a distribution vendor has
backported all the necessary support it can be decreased to a lower
version for distro packages.
This removes the 'two-layer' FuDevice and FuSyanpticsmstDevice model, where
a complicated plugin cache was used to add and remove devices to the daemon.
By making FuSynapticsmstDevice derive from FuDevice rather than GObject we can
also use a lot of the helper functionality like the other plugins, for instance
->prepare_firmware().
The `drm_dp_aux_dev` devices do not emit uevents on unplug/re-plug and so all
devices of `drm` class are watched and the actual DP AUX devices rescanned after
a small delay. When the AUX devices emit changes from the kernel this workaround
can be removed.
Also drop force power support for MST controllers in the Dell plugin. Overall
this has just led to more problems than it's helped.
* Monitor flickers when turned on
* Crashing graphics drivers from time to time
* Fragile logic that doesn't always represent the device state
The test is run if a physical TPM is available or if the environment
variable "TPM_SERVER_RUNNING" is set. In the latter case, the user is
expected to start a TPM simulator on their own, like we do in the Arch
Linux CI script here.
Using the library instead of the command line tools provides a more
stable interface. This implementation only fetches PCR 0 for all
available hash algorithms since this is the only PCR that is actually
used in fwupd.
tpm2_pcrlist has been renamed to tpm2_pcrread in
aedb0291d2
and the output format has changed slightly to include a leading "0x" in
9374bd70f4
Also add an example of the new output format to the self test.
This controller isn't flashable in fwupd, but fwupd can display information
about it.
* Use a generic device ID (similar to safemode)
* Build device name attribute from DMI data
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>
This leads to madness, as some formats are supersets of the detected types,
e.g. 'intel-me' is detected as 'quad' and 'bcd' is detected as 'pair'.
Where the version format is defined in a specification or hardcoded in the
source use a hardcoded enum value, otherwise use a quirk override.
Additionally, warn if the version does not match the defined version format
I'm getting a bit fed up with failed reports from arch users where they just
have a broken system. I don't think it's useful to upload to the LVFS or notify
the vendor about failures like this.
The timeout to wait for the modem after being uninhibited was until
now exclusively to cover the port probing time, because the device
would be already available and ready to be used as soon as the
inhibition was removed.
With the change to include carrier config selection as part of the
fwupd upgrade process, the time to wait for the modem after being
uninhibited should now cover a full reboot of the module, and so the
original timeout of 45s could be a bit tight under some circumstances
(e.g the MM device probing logic is quite slow when there is no SIM
card detected by the module).
We increase this timeout to a much safer value of 120s, which is
extremely long for most cases, but should also be enough to cover even
the worst case scenario.
When we install the MCFG carrier config files with QMI PDC, we were
not explicitly selecting one, and that would end up reporting the
"DF" (default) config is in use. Instead, we should explicitly select
the carrier configuration that we were using before the firmware
upgrade operation.
For example, if the device originally was running with the Vodafone
specific carrier configuration (e.g. T77W968.F1.0.0.3.7.VF.009) and we
trigger the upgrade to the next available firmware associated to
the Vodafone carrier (e.g. T77W968.F1.0.0.3.8.VF.009), we would want
the device to boot with the Vodafone carrier config selected, instead
of booting without any config selected (T77W968.F1.0.0.3.8.DF.009).
This also fixes several upgrade problems detected by fwupd, because it
may end up complaining that the target firmware that was selected to
be installed (e.g. VF variant) is not the one actually reported by the
device after the upgrade (e.g. DF variant).
The selection of which is the config to activate is based on mapping
the mcfg file name with the firmware version reported by the module
before the upgrade. E.g. if the VF variant is reported by the module
(T77W968.F1.0.0.3.7.VF.009), fwupd will look for a MCFG file named
with the "mcfg.VF." prefix.
fu_uefi_get_esp_path_for_os() generates the path to the OS directory
based on "ID" in /etc/os-release, and it may not work for some distros.
Take openSUSE as an example, the "ID" for openSUSE Leap is
"opensuse-leap" and that for openSUSE Tumbleweed is "opensuse-tumbleweed".
However, both of them use the same OS directory in the ESP, i.e.
"/EFI/opensuse".
This commit adds a new build option, efi_os_dir, to allow the packager to
specify the name of OS directory at build time instead of the runtime
detection.
Signed-off-by: Gary Lin <glin@suse.com>
I'm not sure why we can't just use SIO_LDNxx_IDX_CHIPID1, but lets do the same
as the vendor tool in case there is a good reason that I don't know about.
Some system firmware helpfully 'deduplicate' the boot loader entries based on
the filepath, without taking into account either the label or optional data.
This means we have to use a custom copy of shim for firmware updates.
This was caught by LGTM.
This pointer might have type struct <unnamed> (size 28), but the
pointer arithmetic here is done with type UX_CAPSULE_HEADER * (size 16).
This feature is turned on with the new fwupdtool option `--enable-json-state`
The intended use case is for ChromeOS to be able to save information about
devices on the system when `fwupdtool update` was run to display in the UX at
a later time.
If a device reports that qmi-pdc is supported (e.g. DW5821e that
supports both fastboot and qmi-pdc), we'll end up first running the
fastboot installation before doing the qmi-pdc installation procedure.
These changes also make sure that the MM device inhibition is kept for
as long as the whole process is ongoing. Only after the last method is
run, the inhibition will be removed.
In order to handle devices being exposed in the system while the MM
inhibition is in place, e.g. to be able to run qmi-pdc after fastboot,
a simple udev based watcher is included, which will take care of
creating the FuMmDevice that is not associated to any modem currently
exposed by MM, but that shares all the details of the original device.
This new logic assumes that the devices don't change their USB layout
during a firmware upgrade, which is not a very good assumption, but it
works for the case at hand. If this is not the case, we may need to
end up doing some custom AT port probing instead of relying on the
original one reported by MM being still valid (note that we don't rely
on the device name, as that may change if some other device is plugged
in the system while we're doing the update, we rely on the USB
interface number).
This will allow us to switch to the new firmware version during shutdown when
the filesystems have been remounted readonly.
Activating manually means we don't have to get the user to shutdown and then
do a fresh power-on, rather than the more usual restart.
This is intended for devices that it is not safe to immediately activate
the firmware. It may be called at a more convenient time instead.
Both fwupdmgr and fwupdtool support the feature.
- if called at runtime with fwupdmgr it uses the daemon
- during shutdown fwupdtool uses the pending.db to perform this feature.
In some situations SELinux prevents fwupd from executing tpm2_pcrlist, but the
failure mode is that the process just hangs and never completes. This causes
systemd to time out the fwupd daemon startup and then errors to be shown in
GNOME Software.
To prevent this happening, add an optional timeout argument to
fu_common_spawn_sync() and cancel the subprocess if it takes longer than this
to complete.
See https://bugzilla.redhat.com/show_bug.cgi?id=1665701 for details.
The order of events when casting causes an access to unintended memory.
```
0x00007ffff7bc19df in fwupd_guid_to_string (guid=0x8000000090d0, flags=FWUPD_GUID_FLAG_MIXED_ENDIAN) at ../libfwupd/fwupd-common.c:550
550 memcpy (&gnat, guid, sizeof(gnat));
(gdb) bt
#0 0x00007ffff7bc19df in fwupd_guid_to_string (guid=0x8000000090d0, flags=FWUPD_GUID_FLAG_MIXED_ENDIAN) at ../libfwupd/fwupd-common.c:550
#1 0x00007fffdbddd195 in fu_nvme_device_get_guid_safe (buf=0x7fffffffce70 "\\\034\\\034FI83Q060610103M66 BC501 NVMe SK hynix 128GB", ' ' <repeats 15 times>, "80001C0T\004", <incomplete sequence \344\254>, addr_start=3110) at ../plugins/nvme/fu-nvme-device.c:83
#2 0x00007fffdbddd60c in fu_nvme_device_parse_cns_maybe_dell (self=0x5555558cc8a0, buf=0x7fffffffce70 "\\\034\\\034FI83Q060610103M66 BC501 NVMe SK hynix 128GB", ' ' <repeats 15 times>, "80001C0T\004", <incomplete sequence \344\254>) at ../plugins/nvme/fu-nvme-device.c:201
#3 0x00007fffdbddda64 in fu_nvme_device_parse_cns (self=0x5555558cc8a0, buf=0x7fffffffce70 "\\\034\\\034FI83Q060610103M66 BC501 NVMe SK hynix 128GB", ' ' <repeats 15 times>, "80001C0T\004", <incomplete sequence \344\254>, sz=4096, error=0x7fffffffe008) at ../plugins/nvme/fu-nvme-device.c:295
#4 0x00007fffdbddde68 in fu_nvme_device_setup (device=0x5555558cc8a0, error=0x7fffffffe008) at ../plugins/nvme/fu-nvme-device.c:376
#5 0x0000555555587850 in fu_device_setup (self=0x5555558cc8a0, error=0x7fffffffe008) at ../src/fu-device.c:2076
#6 0x0000555555587412 in fu_device_open (self=0x5555558cc8a0, error=0x7fffffffe008) at ../src/fu-device.c:1920
#7 0x000055555558aa88 in fu_device_locker_new_full (device=0x5555558cc8a0, open_func=0x5555555872cb <fu_device_open>, close_func=0x555555587424 <fu_device_close>, error=0x7fffffffe008)
at ../src/fu-device-locker.c:154
#8 0x000055555558a925 in fu_device_locker_new (device=0x5555558cc8a0, error=0x7fffffffe008) at ../src/fu-device-locker.c:104
#9 0x00007fffdbddc4cd in fu_plugin_udev_device_added (plugin=0x5555558a6420, device=0x5555558c6300, error=0x7fffffffe008) at ../plugins/nvme/fu-plugin-nvme.c:24
#10 0x0000555555592cbf in fu_plugin_runner_udev_device_added (self=0x5555558a6420, device=0x5555558c6300, error=0x7fffffffe070) at ../src/fu-plugin.c:1281
#11 0x000055555557f0a8 in fu_engine_udev_device_add (self=0x5555557f9840, udev_device=0x5555558e5900) at ../src/fu-engine.c:3491
#12 0x000055555557f480 in fu_engine_enumerate_udev (self=0x5555557f9840) at ../src/fu-engine.c:3555
#13 0x0000555555580fc6 in fu_engine_load (self=0x5555557f9840, error=0x7fffffffe2c8) at ../src/fu-engine.c:4117
#14 0x0000555555566567 in fu_util_start_engine (priv=0x5555557eeb20, error=0x7fffffffe2c8) at ../src/fu-tool.c:138
#15 0x00005555555674e2 in fu_util_get_devices (priv=0x5555557eeb20, values=0x7fffffffe5d8, error=0x7fffffffe2c8) at ../src/fu-tool.c:490
#16 0x0000555555566aff in fu_util_run (priv=0x5555557eeb20, command=0x7fffffffe81a "get-devices", values=0x7fffffffe5d8, error=0x7fffffffe2c8) at ../src/fu-tool.c:242
#17 0x000055555556a514 in main (argc=2, argv=0x7fffffffe5c8) at ../src/fu-tool.c:1445
```
EC23 is the last version that will be supported on board 4 SKUs with
base PD firmware versions 18+.
* If on EC23 already, don't mark the device as updatable anymore.
* Flashing EC24 or later when currently on EC 22 or less will potentially
cause bricked docks that can't enumerate, so prevent this scenario
during update path.
The unifying version numbers are of the form 'RQR24.00_B0000' which means we
have to force the plugin to 'plain' version format to avoid stripping out the
non-semver chars.
Fixes https://github.com/hughsie/fwupd/issues/1018
The udev plugin is somewhat special as it uses a non-subclassed FuDevice that
never gets 'opened'.
This means that we never automatically call fu_device_setup() and thus the
instance IDs are not converted into GUIDs before the device is added.
