The CustomFlags feature is a bit of a hack where we just join the flags
and store in the device metadata section as a string. This makes it
inefficient to check if just one flag exists as we have to split the
string to a temporary array each time.
Rather than adding to the hack by splitting, appending (if not exists)
then joining again, store the flags in the plugin privdata directly.
This allows us to support negating custom properties (e.g. ~hint) and
also allows quirks to append custom values without duplicating them on
each GUID match, e.g.
[USB\VID_17EF&PID_307F]
Plugin = customflag1
[USB\VID_17EF&PID_307F&HUB_0002]
Flags = customflag2
...would result in customflag1,customflag2 which is the same as you'd
get from an enumerated device flag doing the same thing.
Data is accessed at offset 0x13, so the code must abort if size is
0x13 when you can access only offsets 0x00 through 0x12.
Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
On Alterlake and newer hardware the Platform Health Assessment Record
data can be used by the IHV to debug why a specific capsule update
failed. Any custom firmware loaded by the OEM can be identified and
used to further debug the root cause.
The dependencies to generate the "updating..." splash screen are non-trivial, and
pointless in headless systems. Add an option to disable the generation entirely.
This prevents problems when cross compiling. Using help2man is now also of
limited use; if we can just tell the user to use --help we do not need to keep
the manual in sync.
It also allows us to drop the several other supporting files that we use when
the help2man output isn't actually that useful.
Fixes https://github.com/fwupd/fwupd/issues/3025
Due the lack of pei-aarch64 support in binutils, the gnu-efi crt0 harcodes
the PE32+ sections among other things. These crt0 aren't aware of the SBAT
section and so custom ones have to be used.
In the same vein as commit cfd1f2f42a ("uefi-capsule: Ensure SBAT metadata
is added correctly") included custom linker scripts, this change add a set
of crt0 for arm and aarch64 that hardcode a SBAT section in the PE headers.
These are the crt0 from gnu-efi plus the following fixes from Peter Jones:
* Include .sbat in section headers
* Fix some PE headers
* Calculate the VirtualSize of .sbat separately
* Put .rel* and .dyn* in .rodata
The linker scripts used in the project were copied from the shim project,
but there were a few fixes made after this original copy.
Until binutils have proper pei-aarch64 support, the linker scripts should
be kept in sync to make sure that the PE32+ binaries are built correctly.
The fixes included in this change are the following:
* Include missing .text sections in PE/COFF binary (Chris Coulson)
* Put .sbat after _edata (Peter Jones)
* Fix some PE headers for arm and aarch64 (Peter Jones)
* Include the aligned part in SizeOfRawData of sbat for arm and aarch64 (Gary Lin)
* Swizzle some sections to make old sbsign happier for arm and aarch64 (Peter Jones)
* Put .rel* and .dyn* in .rodata for arm and aarch64 (Peter Jones)
There is a lot of code in fwupd that just assigns a shared object type to
a FuPlugin, and then for each device on that plugin assigns that same shared
object to each FuDevice.
Rather than proxy several kinds of information stores over two different levels
of abstraction create a 'context' which contains the shared *system* state
between the daemon, the plugins and the daemon.
This will allow us to hold other per-machine state in the future, for instance
the system battery level or AC state.
We already have two things managing the UPDATABLE_HIDDEN->UPDATABLE transition,
and we're about to add a third.
Add a 'stackable' inhibit-style API so we do not accidentally mark a device as
updatable when it should remain hidden.
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
