Commit Graph

9 Commits

Author SHA1 Message Date
Mario Limonciello
6d1afc3e87 trivial: reformat all python code with black 2021-04-08 10:43:29 -05:00
Javier Martinez Canillas
f2327011a7 uefi-capsule: Include crt0 for arm and aarch64 that add a SBAT section
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
2021-04-07 13:46:58 +01:00
Chris Coulson
cfd1f2f42a uefi-capsule: Ensure SBAT metadata is added correctly
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.
2021-02-22 16:19:19 +00:00
Richard Hughes
9df6764d93 uefi-capsule: Set the component generation to 1
See https://github.com/rhboot/shim/blob/main/SBAT.md
2021-02-18 13:23:18 -06:00
Richard Hughes
ec52942bc5 uefi-capsule: Include all the sections when using objcopy
Fixes the regression introduced in fde4b1676a
2021-02-18 13:23:18 -06:00
Richard Hughes
6d656a940d Allow building without SBAT metadata
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
2021-02-16 11:04:47 +00:00
Javier Martinez Canillas
17c0a6c239 uefi-capsule: Fix objcopy failing to add a .sbat section on aarch64
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>
2021-02-12 13:29:55 +00:00
Javier Martinez Canillas
378b00018b uefi-capsule: Add SBAT metadata to the fwupd EFI binary
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
2021-02-10 16:40:59 +00:00
Javier Martinez Canillas
fde4b1676a uefi: Rewrite generate_binary.sh script in Python
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.
2021-02-04 12:51:05 +00:00