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
The only real value of the optionrom plugin is the ability to store and verify
the ROM checksum; parsing the image is not actually required and is a source of
anxiety for various security teams.
There are now two 'backends' of device plug/unplug events, and there is about
to become three. Rather than just adding two more vfuncs for every backend type
define common ones that all providers can use.
Also fix up the existing in-tree plugins to use the new vfunc names and filter
on the correct GType.
The generate_binary.sh is a script that calls the objcopy tool and
genpeimg in the case of Windows, to generate a PE binary file.
But doesn't have to be a shell script and could be rewritten as a
python script. This will make this code to generate a PE binary
easier to extend if needed.
Also, the only reason that's a template is to define the objcopy
tool used, but this can also be passed as a positional argument.
This allows us to check that the plugin is writing into a mutable buffer. Also
fix up the plugins that are currently 'wrong' and use the new function for the
plugins doing the right thing.
At the moment FuChunks are sometimes mutable, and sometimes immutable, and it's
all a bit too low level for comfort.
Before we can do any kind of optimisation or verification we need plugins to
stop reading directly from the C structure. The aim here is to make FuChunk
optionally mutable without making assumptions about the memory model, and also
to be able to introspect it for the docs.
This bootloader is *weird* -- the chip ID is the first two bytes of the serial
number and the data is offset and encoded in UTF-8, not UTF-16.
The sector information is also wrong. Gah!
Some systems remove the BootXXXX entry we add (so we can run fwupdx64.efi) and
thus the firmware update does not run. Most commonly this failure is seen with
Lenovo systems that call the helpful option 'Boot Order Lock'.
Hopefully when we depend on the new kernel bios interface sysfs API in we can
check in ->prepare(), not after reboot, but until that we can mark the update
failure as transient as the user can actually fix the problem themselves.
Fixes https://github.com/fwupd/fwupd/issues/2801
This plugin supports reading the keyboard firmware version at runtime and
rebooting the keyboard to USB DFU mode. Tested with firmware uploaded to
embargo-system76.
When this is done, include:
* Including the hash
* Including anything that is not ABI stable in plugins yet
Suggested-by: Simon McVittie <smcv@debian.org>
This allows much better compression (-60%) than gziping them individually and
also allows us to build the capsule UX images as part of the build stage.
Also add more popular screen resolutions for laptops you can buy in 2021.
The coreboot plugin never actually gained the ability to write. As it stands a
coreboot system now adds *two* system-firmware devices (from both flashrom and
coreboot) which isn't ideal.
Just allow flashrom to enumerate quirked devices and add coreboot-specific
metadata as required. If we require some kind of cbfs parsing then we can do
that in FuFlashromDevice->prepare_firmware().
Although we could reconstruct the PCR0 value on the LVFS from the (already
included) event log, it's much more scalable if the client just provides the
data that we want to filter by.
I was asked the other day how many machines would support a /dev/mem mmap'd
update mechanism, and I had to say that I didn't know. We use direct port IO in
the SuperIO plugin too, and it would be good to know how quickly we need to
port this to something else.
It's unusual, but if BIOS lock enable is enabled (so we cannot *change* the
value of BIOSWE) but the BIOS is already WE then we can write to the hardware
just fine.
Once a device has been scheduled for update mark the others from the same plugin
as updatable-hidden rather than updatable so that fwupdmgr or gnome-software
does not try to offer updates for them.
This is preferable to quitting with an error in FuDevice->prepare as we don't
want to waste bandwidth downloading the next update and then show the user an
error they can't possibly understand.
Exclude the currently scheduled device to allow the user to change the scheduled
release and so the pending device does not disappear from UI tools.
