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
