Deleting boot entries from EFI sometimes triggers problems on some firmware.
We don't actually need to do it from the EFI binary, and it's perfectly safe to
leave it in the boot list. It also means when doing multiple updates over
several months we're not creating, deleting, creating, deleting and can just
re-use the same BootXXXX number each time.
It also makes the EFI binary simpler, which is good.
At the moment fwupd creates a BootXXXX for fwupd.efi and marks it BootNext.
It *also* adds it to the end of BootOrder to work around various old firmware
bugs like https://github.com/rhboot/fwupdate/issues/55 which we can perhaps
drop sometime thie century.
Remove the rewriting of BootOrder from the EFI binary; we've accidentally not
been doing it for a long time and nothing broke, and I'd like to make the EFI
binary as small and simple as possible. The user can remove the entry from the
BIOS or using efibootmgr if required, but it's harmless to just leave it.
This reverts commit 44f55e2ee6.
This behavior caused fwupdx64.efi to loop for a very long time until
either aborting, running out of memory or some other problems.
Fixes: #1756Fixes: #1751
gnu-efi 3.0.11 moves a few files around, e.g.
/usr/lib64/gnuefi/elf_x64_efi.lds -> /usr/lib64/gnuefi/x64/efi.lds
...and this causes the UEFI EFI helper to fail to link.
Add support for the 'new' paths and fall back to the old ones.
Fixes https://github.com/fwupd/fwupd/issues/1736
UEFI runtime service GetVariable with DataSize NULL, will fail and get
EFI_INVALID_PARAMETER returned. Set DataSize 0 and allocate the buffer for
getting attributes for the deleted variable.
Also, fix the real reason Boot#### was never found.
We don't actually need either of the things it provides (looking up in source
and built, and converting to an absolute path) so just replace it with
g_build_filename() instead.
This also has the advantage that it does the right thing on Windows.
Some plugins have devices with more than one protocol. Logically the protocol
belongs to the device, not the plugin, and in the future we could use this to
further check firmware that's about to be deployed.
This is also not exported into libfwupd (yet?) as it's remains a debug-feature
only -- protocols are not actually required for devices to be added.
This makes everything simpler, at the expense of not being able to create a
`BootFFFF` entry -- but if we get that far something has already gone very
wrong with the firmware...
Some derivative distributions re-use bootloader paths from their
upstream. When this happens the current logic to look for the `ID`
key in `/etc/os-release` doesn't work properly.
Adjust the logic to:
1) Use `ID`
2) Test the path exists. If so, use it.
3) If it doesn't use `ID_LIKE`.
4) Test if that path exists, if so use it.
5) If that path doesn't exist, return the key from `ID`
6) The plugin will make this path.
The GNU gold linker uses the section name `.rela.dyn` instead of
`.rela` for containing the relocation information. If this section
is not copied the EFI executable can crash.
Fixes#1530
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.
