Revision tags: v6.6.25, v6.6.24, v6.6.23, v6.6.16, v6.6.15, v6.6.14, v6.6.13, v6.6.12, v6.6.11, v6.6.10, v6.6.9, v6.6.8, v6.6.7, v6.6.6, v6.6.5, v6.6.4, v6.6.3, v6.6.2, v6.5.11, v6.6.1, v6.5.10, v6.6, v6.5.9, v6.5.8, v6.5.7, v6.5.6, v6.5.5, v6.5.4, v6.5.3, v6.5.2, v6.1.51, v6.5.1, v6.1.50, v6.5, v6.1.49, v6.1.48, v6.1.46, v6.1.45, v6.1.44, v6.1.43, v6.1.42, v6.1.41, v6.1.40, v6.1.39, v6.1.38, v6.1.37, v6.1.36, v6.4, v6.1.35, v6.1.34, v6.1.33, v6.1.32, v6.1.31, v6.1.30 |
|
#
095aabe3 |
| 22-May-2023 |
Ard Biesheuvel <ardb@kernel.org> |
efi/libstub: zboot: Avoid eager evaluation of objcopy flags
The Make variable containing the objcopy flags may be constructed from the output of build tools operating on build artifacts, and these m
efi/libstub: zboot: Avoid eager evaluation of objcopy flags
The Make variable containing the objcopy flags may be constructed from the output of build tools operating on build artifacts, and these may not exist when doing a make clean.
So avoid evaluating them eagerly, to prevent spurious build warnings.
Suggested-by: Pedro Falcato <pedro.falcato@gmail.com> Tested-by: Alan Bartlett <ajb@elrepo.org> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
show more ...
|
Revision tags: v6.1.29, v6.1.28, v6.1.27, v6.1.26, v6.3, v6.1.25 |
|
#
026b8579 |
| 18-Apr-2023 |
Ard Biesheuvel <ardb@kernel.org> |
efi/zboot: arm64: Grab code size from ELF symbol in payload
Instead of relying on a dodgy dd hack to copy the image code size from the uncompressed image's PE header to the end of the compressed ima
efi/zboot: arm64: Grab code size from ELF symbol in payload
Instead of relying on a dodgy dd hack to copy the image code size from the uncompressed image's PE header to the end of the compressed image, let's grab the code size from the symbol that is injected into the ELF object by the Kbuild rules that generate the compressed payload.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Acked-by: Mark Rutland <mark.rutland@arm.com>
show more ...
|
#
45dd403d |
| 18-Apr-2023 |
Ard Biesheuvel <ardb@kernel.org> |
efi/zboot: arm64: Inject kernel code size symbol into the zboot payload
The EFI zboot code is not built as part of the kernel proper, like the ordinary EFI stub, but still needs access to symbols th
efi/zboot: arm64: Inject kernel code size symbol into the zboot payload
The EFI zboot code is not built as part of the kernel proper, like the ordinary EFI stub, but still needs access to symbols that are defined only internally in the kernel, and are left unexposed deliberately to avoid creating ABI inadvertently that we're stuck with later.
So capture the kernel code size of the kernel image, and inject it as an ELF symbol into the object that contains the compressed payload, where it will be accessible to zboot code that needs it.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Acked-by: Mark Rutland <mark.rutland@arm.com>
show more ...
|
#
538bc0f4 |
| 18-Apr-2023 |
Ard Biesheuvel <ardb@kernel.org> |
efi/zboot: Set forward edge CFI compat header flag if supported
Add some plumbing to the zboot EFI header generation to set the newly introduced DllCharacteristicsEx flag associated with forward edg
efi/zboot: Set forward edge CFI compat header flag if supported
Add some plumbing to the zboot EFI header generation to set the newly introduced DllCharacteristicsEx flag associated with forward edge CFI enforcement instructions (BTI on arm64, IBT on x86)
x86 does not currently uses the zboot infrastructure, so let's wire it up only for arm64.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
show more ...
|
#
bca2f3a9 |
| 18-Apr-2023 |
Ard Biesheuvel <ardb@kernel.org> |
efi/zboot: Add BSS padding before compression
We don't really care about the size of the decompressed image - what matters is how much space needs to be allocated for the image to execute, and this
efi/zboot: Add BSS padding before compression
We don't really care about the size of the decompressed image - what matters is how much space needs to be allocated for the image to execute, and this includes space for BSS that is not part of the loadable image and so it is not accounted for in the decompressed size.
So let's add some zero padding to the end of the image: this compresses well, and it ensures that BSS is accounted for, and as a bonus, it will be zeroed before launching the image.
Since all architectures that implement support for EFI zboot carry this value in the header in the same location, we can just grab it from the binary that is being compressed.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
show more ...
|
Revision tags: v6.1.24, v6.1.23, v6.1.22, v6.1.21 |
|
#
97fd768e |
| 21-Mar-2023 |
Ard Biesheuvel <ardb@kernel.org> |
efi/libstub: zboot: Add compressed image to make targets
Avoid needlessly rebuilding the compressed image by adding the file 'vmlinuz' to the 'targets' Kbuild make variable.
Signed-off-by: Ard Bies
efi/libstub: zboot: Add compressed image to make targets
Avoid needlessly rebuilding the compressed image by adding the file 'vmlinuz' to the 'targets' Kbuild make variable.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
show more ...
|
Revision tags: v6.1.20, v6.1.19, v6.1.18, v6.1.17, v6.1.16, v6.1.15, v6.1.14, v6.1.13, v6.2, v6.1.12, v6.1.11, v6.1.10, v6.1.9, v6.1.8, v6.1.7, v6.1.6, v6.1.5, v6.0.19, v6.0.18, v6.1.4, v6.1.3, v6.0.17, v6.1.2, v6.0.16, v6.1.1, v6.0.15, v6.0.14, v6.0.13, v6.1, v6.0.12, v6.0.11, v6.0.10, v5.15.80, v6.0.9, v5.15.79, v6.0.8, v5.15.78, v6.0.7, v5.15.77, v5.15.76, v6.0.6, v6.0.5, v5.15.75, v6.0.4, v6.0.3, v6.0.2, v5.15.74 |
|
#
1f1ba325 |
| 12-Oct-2022 |
Ard Biesheuvel <ardb@kernel.org> |
efi: libstub: Add image code and data size to the zimage metadata
In order to be able to switch from LoadImage() [which treats the supplied PE/COFF image as file input only, and reconstructs the mem
efi: libstub: Add image code and data size to the zimage metadata
In order to be able to switch from LoadImage() [which treats the supplied PE/COFF image as file input only, and reconstructs the memory image based on the section descriptors] to a mode where we allocate the memory directly, and invoke the image in place, we need to now how much memory to allocate beyond the end of the image. So copy this information from the payload's PE/COFF header to the end of the compressed version of the payload, so that the decompressor app can access it before performing the decompression itself.
We'll also need to size of the code region once we switch arm64 to jumping to the kernel proper with MMU and caches enabled, so let's capture that information as well. Note that SizeOfCode does not account for the header, so we need SizeOfHeaders as well.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
show more ...
|
#
f57fb375 |
| 17-Oct-2022 |
Ard Biesheuvel <ardb@kernel.org> |
efi: libstub: Remove zboot signing from build options
The zboot decompressor series introduced a feature to sign the PE/COFF kernel image for secure boot as part of the kernel build. This was necess
efi: libstub: Remove zboot signing from build options
The zboot decompressor series introduced a feature to sign the PE/COFF kernel image for secure boot as part of the kernel build. This was necessary because there are actually two images that need to be signed: the kernel with the EFI stub attached, and the decompressor application.
This is a bit of a burden, because it means that the images must be signed on the the same system that performs the build, and this is not realistic for distros.
During the next cycle, we will introduce changes to the zboot code so that the inner image no longer needs to be signed. This means that the outer PE/COFF image can be handled as usual, and be signed later in the release process.
Let's remove the associated Kconfig options now so that they don't end up in a LTS release while already being deprecated.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
show more ...
|
Revision tags: v5.15.73, v6.0.1, v5.15.72, v6.0, v5.15.71, v5.15.70, v5.15.69, v5.15.68, v5.15.67, v5.15.66, v5.15.65, v5.15.64, v5.15.63, v5.15.62, v5.15.61, v5.15.60, v5.15.59, v5.19, v5.15.58, v5.15.57, v5.15.56, v5.15.55, v5.15.54, v5.15.53, v5.15.52, v5.15.51, v5.15.50, v5.15.49, v5.15.48, v5.15.47, v5.15.46, v5.15.45, v5.15.44, v5.15.43, v5.15.42, v5.18, v5.15.41, v5.15.40, v5.15.39, v5.15.38 |
|
#
a0509109 |
| 01-May-2022 |
Ard Biesheuvel <ardb@kernel.org> |
efi/libstub: implement generic EFI zboot
Implement a minimal EFI app that decompresses the real kernel image and launches it using the firmware's LoadImage and StartImage boot services. This removes
efi/libstub: implement generic EFI zboot
Implement a minimal EFI app that decompresses the real kernel image and launches it using the firmware's LoadImage and StartImage boot services. This removes the need for any arch-specific hacks.
Note that on systems that have UEFI secure boot policies enabled, LoadImage/StartImage require images to be signed, or their hashes known a priori, in order to be permitted to boot.
There are various possible strategies to work around this requirement, but they all rely either on overriding internal PI/DXE protocols (which are not part of the EFI spec) or omitting the firmware provided LoadImage() and StartImage() boot services, which is also undesirable, given that they encapsulate platform specific policies related to secure boot and measured boot, but also related to memory permissions (whether or not and which types of heap allocations have both write and execute permissions.)
The only generic and truly portable way around this is to simply sign both the inner and the outer image with the same key/cert pair, so this is what is implemented here.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
show more ...
|