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.
