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.
