During startup we do 1898 persistent allocations to load the quirk files, which
equates to ~90kb of RSS. Use libxmlb to create a mmap'able store we can query
with XPath queries at runtime.
This makes the daemon less destructive at startup, especially if the ESP
is not mounted.
It's stored in 3 different places right now, so move it into one point of truth.
Now the ESP is detected when needed including all point of time safety checks and
dynamically mounted and unmounted if necessary.
I was seeing on a CML laptop with a Nuvoton TPM the following which
is definitely wrong:
```
Checksum: SHA1(791183aa2c4993dfaf75e95c91bdad067ac2cce1)
Checksum: SHA256(8a0656fe0024cc3300cc4dc8af4fc336112a51013aeb74b21c138ed116bb8691)
Checksum: SHA1(000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000)
```
Although they can be useful for debugging the codepath leading to
a problem, they are also confusing when it comes to the end user
messages:
```
{error #0} linux.c:406 device_get(): readlink of /sys/block/nvme0n1/device/driver failed: No such file or directory
{error #1} linux.c:406 device_get(): readlink of /sys/block/nvme0n1/device/driver failed: No such file or directory
{error #2} linux.c:406 device_get(): readlink of /sys/block/nvme0n1/device/driver failed: No such file or directory
{error #3} linux.c:406 device_get(): readlink of /sys/block/nvme0n1/device/driver failed: No such file or directory:
Error writing to file descriptor: No space left on device
```
Whereas if they weren't shown, that last message would have been plenty.
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
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
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.
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.
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.
* 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 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.
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>
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).
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.
Some hardware from Lenovo deduplicates UEFI Boot entries, and uses the old
string 'Linux-Firmware-Updater' to avoid removing the firmware update entry.
Although this is forbidden in the UEFI specification we shouldn't break
firmware updates from old firmware versions.
Provide a quirk for this, and automatically whitelist anything with the LENOVO
SMBIOS Manufacturer.
Unfortunately the previous fix (6131f5d) introduced this bug.
The code previously was actually looking for the non-zero case
which was correct, but non-obvious since `efi_guid_cmp` works like
`g_strcmp0` where a match returns zero.
So rather than revert 6131f5d make this completly explicit.
Microsoft description about the Status is:
The Status field of the BGRT describes whether the image is currently
displayed on the screen. This is not applicable to the firmware update
display capsule.
Many thanks to Steven Chang for identifying this issue.
Fixes: https://github.com/hughsie/fwupd/issues/935
We can't actually access the UEFI ROM from userspace, but the PCR0 is a hash
built from the ROM itself. We could use this value to ensure the firmware has
been written correctly, and that the PCR0 matches the expected value specified
in the metadata.
Future metadata from the LVFS will set the protocol the firmware is expected to
use. As vendors love to re-use common terms like DFU for incompatible protocols,
namespace them with the controlling company ID with an approximate reverse DNS
namespace.
This also allows more than one plugin to define support for the same protocol,
for instance rts54hid+rts54hub and synapticsmst+dell-dock.
This solves issues with implementations that require 4k alignment
of pages in BIOS which is seen on certain architectures.
The UEFI spec prescribes that the "minimum" size is the size of
the EFI header but that this may be increased up to larger sizes
due to extended header entries.
