Rather than trying to guess typos, force each plugin to register the quirk
keys it supports, so we can show a sensible warning if required at startup on
the console.
The best way of not getting something wrong is to not require it in the first
place...
All plugins now use DeviceInstanceId-style quirk matches and we can just drop
the prefix in all files. We were treating HwId=, Guid= and DeviceInstanceId= in
exactly the same way -- they're just converted to GUIDs when building the silo!
This means we can use the standard ->set_quirk_kv() vfunc rather than using
FuQuirks directly with a custom group. Also use a plugin prefix for quirk keys.
At the moment plugins are doing this a few different ways; either looping
through the HwIds manually (e.g. flashrom) or setting a custom flag that is
checked in fu_plugin_setup (e.g. uefi-recovery).
Define a standard 'Plugin' HwId quirk to simplify plugins.
Devices may want to support more than one protocol, and for some devices
(e.g. Unifying peripherals stuck in bootloader mode) you might not even be able
to query for the correct protocol anyway.
This is effectively a lot of dead code.
* The minimum requirements for this feature are EC 00.00.00.23 and Hub2 1.42.
* "A00" docks shipped with EC 01.00.00.00 and Hub2 1.47
It is far too easy to forget to set FWUPD_DEVICE_FLAG_NO_GUID_MATCHING for new
plugins, and without it it all works really well *until* a user has two devices
of the same type installed at the same time and then one 'disappears' for hard
to explain reasons. Typically we only need it for replug anyway!
Explicitly opt-in to this rarely-required behaviour, with the default to just
use the physical and logical IDs. Also document the update behavior for each
plugin to explain why the flag is being used.
This allows you to have two identical Unifying plugged in without one of them
being hidden from the user, at the same time allowing a HIDRAW<->USB transition
when going to and from bootloader and runtime modes.
This removes the workaround added in 99eb3f06b6.
Fixes https://github.com/fwupd/fwupd/issues/2915
The current approach of adding SBAT metadata after linking is creating
an image that is badly formed in 2 ways:
* The SBAT section's file offset and size are not a multiple of the
file alignment.
* The SBAT section has a virtual address of zero. EDK2 loads the header
here, and so it gets rejected.
This changes the approach to match shim, where an object file is
created with a .sbat section and then the linker takes care of placing
the section at a more appropriate virtual address.
See https://github.com/vathpela/gnu-efi/pull/14 for the section addition.
This is typically when the OEM is using the reference hardware design.
Prevent updates, as there might be a new bug introduced in the reference
firmware that only manifests on one OEM's product. It's up to the OEM to do the
testing and validation.
We need something to tie it back to a physical device model if it's using a
reference firmware and we want to update it.
Also split out the firmware parsing to an object so we can check the firmware
using firmware-parse and also fuzz it.
See also: https://github.com/fwupd/fwupd/issues/1665
This allows a device subclass to call the parent method after doing an initial
action, or even deliberately not call the *generic* parent method at all.
It also simplifies the plugins; you no longer have to remember what the plugin
is deriving from and accidentally clobber the wrong superclass method.
Otherwise the following build error happens:
../fwupd-1.5.6/plugins/system76-launch/fu-system76-launch-device.c:117:9: error: ‘G_USB_DEVICE_CLAIM_INTERFACE_BIND_KERNEL_DRIVER’ undeclared (first use in this function)
117 | G_USB_DEVICE_CLAIM_INTERFACE_BIND_KERNEL_DRIVER,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../fwupd-1.5.6/plugins/system76-launch/fu-system76-launch-device.c:133:11: error: ‘G_USB_DEVICE_CLAIM_INTERFACE_BIND_KERNEL_DRIVER’ undeclared (first use in this function)
133 | G_USB_DEVICE_CLAIM_INTERFACE_BIND_KERNEL_DRIVER,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Two reasons:
* It seems a bit antisocial to hard-require all this data without fair warning
* The aarch64 pesign crashes when trying to sign the binary with SBAT metadata
We happily fallback with an unset -Defi_os_dir and it gets confusing explaining
why the EFI dir needs to be set on a non-supported system.
In practice they'll probably have the same eventual value on most supported
distributions.
Fixes https://github.com/fwupd/fwupd/issues/2873
The objcopy tool only has support for pei-x86_64 and pei-i386 targets, and
so trying to add a .sbat section for fwupdaa64.efi fails with this error:
objcopy: plugins/uefi-capsule/efi/fwupdaa64.efi: file format not recognized
To fix this issue, add the .sbat section to the ELF fwup.so shared object
and keep that section when generating the resulting fwupdaa64.efi binary.
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
The Secure Boot Advanced Targeting (SBAT) [0] is a Generation Number Based
Revocation mechanism that is meant to replace the DBX revocation file list.
Binaries must contain a .sbat data section that has a set entries, each of
them consisting of UTF-8 strings as comma separated values. Allow to embed
this information into the fwupd EFI binary at build time.
The SBAT metadata must contain at least two entries. One that defines the
SBAT version used and another one that defines the component generation.
Downstream users can add additional entries if have changes that make them
diverge from the upstream code and potentially add other vulnerabilities.
[0]: https://github.com/rhboot/shim/blob/sbat/SBAT.md
