This allows us to 'nest' firmware formats, and removes a ton of duplication.
The aim here is to deprecate FuFirmwareImage -- it's almost always acting
as a 'child' FuFirmware instance, and even copies most of the vfuncs to allow
custom types. If I'm struggling to work out what should be a FuFirmware and
what should be a FuFirmwareImage then a plugin author has no hope.
For simple payloads we were adding bytes into an image and then the image into
a firmware. This gets really messy when most plugins are treating the FuFirmware
*as* the binary firmware file.
The GBytes saved in the FuFirmware would be considered the payload with the
aim of not using FuFirmwareImage in the single-image case.
When using "objcopy -O binary" to generate AArch64 EFI images, it
silently drops the sections without "alloc" or "load" or the sections
with "unload", and this caused the content of .sbat was skipped in the
final EFI image.
This commit sets the common read-only data section flags to .sbat to
make sure the content will be copied.
Signed-off-by: Gary Lin <glin@suse.com>
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!
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.
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.
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 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.
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
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.
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.
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.
in ee2e2c3674 the plugin name was changed
from uefi to uefi_capsule. while the config file name was changed, the
section name should also be changed.
fixes#2748
The end year is legally and functionally redundant, and more importantly causes
cherry-pick conflicts when trying to maintain old branches. Use git for history.
That giant uint64_t isn't looking so big now, and we'll want to add even more
to it in the future. Split out some private flags that are never useful to the
client, although the #defines will have to remain until we break API again.
