public-mirrors/linux
1
0
Fork 0
mirror of git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git synced 2025-08-05 16:54:27 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions
linux/drivers/firmware/efi/libstub/zboot.lds

64 lines
1 KiB
Text
Raw Permalink Normal View History

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>
2022-05-02 01:08:16 +02:00
/* SPDX-License-Identifier: GPL-2.0 */
ENTRY(__efistub_efi_zboot_header);
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>
2023-04-18 15:49:49 +02:00
PROVIDE(zboot_code_size = ABSOLUTE(0));
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>
2022-05-02 01:08:16 +02:00
SECTIONS
{
.head : ALIGN(4096) {
*(.head)
}
.text : {
*(.text* .init.text*)
}
.rodata : ALIGN(8) {
__efistub__gzdata_start = .;
*(.gzdata)
efi/libstub: Avoid legacy decompressor zlib/zstd wrappers Remove EFI zboot's dependency on the decompression wrappers used by the legacy decompressor boot code, which can only process the input in one go, and this will not work for upcoming support for embedded ELF images. They also do some odd things like providing a barebones malloc() implementation, which is not needed in a hosted environment such as the EFI boot services. So instead, implement GZIP deflate and ZSTD decompression in terms of the underlying libraries. Support for other compression algoritms has already been dropped. Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2024-11-20 20:36:03 +01:00
__efistub_payload_size = . - 4;
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>
2022-05-02 01:08:16 +02:00
__efistub__gzdata_end = .;
*(.rodata* .init.rodata* .srodata*)
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>
2023-04-18 15:49:49 +02:00
. = ALIGN(4);
__efistub_code_size = .;
LONG(zboot_code_size);
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>
2022-05-02 01:08:16 +02:00
_etext = ALIGN(4096);
. = _etext;
}
efi: zboot specific mechanism for embedding SBAT section SBAT is a mechanism which improves SecureBoot revocations of UEFI binaries by introducing a generation-based technique. Compromised or vulnerable UEFI binaries can be prevented from booting by bumping the minimal required generation for the specific component in the bootloader. More information on the SBAT can be obtained here: https://github.com/rhboot/shim/blob/main/SBAT.md Upstream Linux kernel does not currently participate in any way in SBAT as there's no existing policy in how SBAT generation number should be defined. Keep the status quo and provide a mechanism for distro vendors and anyone else who signs their kernel for SecureBoot to include their own SBAT data. This leaves the decision on the policy to the vendor. Basically, each distro implementing SecureBoot today, will have an option to inject their own SBAT data during kernel build and before it gets signed by their SecureBoot CA. Different distro do not need to agree on the common SBAT component names or generation numbers as each distro ships its own 'shim' with their own 'vendor_cert'/'vendor_db' Implement support for embedding SBAT data for architectures using zboot (arm64, loongarch, riscv). Put '.sbat' section in between '.data' and '.text' as the former also covers '.bss' and thus must be the last one. Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2025-05-13 14:58:07 +02:00
.sbat : ALIGN(4096) {
_sbat = .;
*(.sbat)
_esbat = ALIGN(4096);
. = _esbat;
}
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>
2022-05-02 01:08:16 +02:00
.data : ALIGN(4096) {
efi: zboot specific mechanism for embedding SBAT section SBAT is a mechanism which improves SecureBoot revocations of UEFI binaries by introducing a generation-based technique. Compromised or vulnerable UEFI binaries can be prevented from booting by bumping the minimal required generation for the specific component in the bootloader. More information on the SBAT can be obtained here: https://github.com/rhboot/shim/blob/main/SBAT.md Upstream Linux kernel does not currently participate in any way in SBAT as there's no existing policy in how SBAT generation number should be defined. Keep the status quo and provide a mechanism for distro vendors and anyone else who signs their kernel for SecureBoot to include their own SBAT data. This leaves the decision on the policy to the vendor. Basically, each distro implementing SecureBoot today, will have an option to inject their own SBAT data during kernel build and before it gets signed by their SecureBoot CA. Different distro do not need to agree on the common SBAT component names or generation numbers as each distro ships its own 'shim' with their own 'vendor_cert'/'vendor_db' Implement support for embedding SBAT data for architectures using zboot (arm64, loongarch, riscv). Put '.sbat' section in between '.data' and '.text' as the former also covers '.bss' and thus must be the last one. Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2025-05-13 14:58:07 +02:00
_data = .;
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>
2022-05-02 01:08:16 +02:00
*(.data* .init.data*)
_edata = ALIGN(512);
. = _edata;
}
.bss : {
*(.bss* .init.bss*)
_end = ALIGN(512);
. = _end;
}
/DISCARD/ : {
efi/libstub: zboot.lds: Discard .discard sections When building ARCH=loongarch defconfig + CONFIG_UNWINDER_ORC=y using LLVM, there is a warning from ld.lld when linking the EFI zboot image due to the use of unreachable() in number() in vsprintf.c: ld.lld: warning: drivers/firmware/efi/libstub/lib.a(vsprintf.stub.o):(.discard.unreachable+0x0): has non-ABS relocation R_LARCH_32_PCREL against symbol '' If the compiler cannot eliminate the default case for any reason, the .discard.unreachable section will remain in the final binary but the entire point of any section prefixed with .discard is that it is only used at compile time, so it can be discarded via /DISCARD/ in a linker script. The asm-generic vmlinux.lds.h includes .discard and .discard.* in the COMMON_DISCARDS macro but that is not used for zboot.lds, as it is not a kernel image linker script. Add .discard and .discard.* to /DISCARD/ in zboot.lds, so that any sections meant to be discarded at link time are not included in the final zboot image. This issue is not specific to LoongArch, it is just the first architecture to select CONFIG_OBJTOOL, which defines annotate_unreachable() as an asm statement to add the .discard.unreachable section, and use the EFI stub. Closes: https://github.com/ClangBuiltLinux/linux/issues/2023 Signed-off-by: Nathan Chancellor <nathan@kernel.org> Acked-by: Huacai Chen <chenhuacai@loongson.cn> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2024-05-22 10:32:43 -07:00
*(.discard .discard.*)
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>
2022-05-02 01:08:16 +02:00
*(.modinfo .init.modinfo)
}
}
efi: libstub: Fix incorrect payload size in zboot header The linker script symbol definition that captures the size of the compressed payload inside the zboot decompressor (which is exposed via the image header) refers to '.' for the end of the region, which does not give the correct result as the expression is not placed at the end of the payload. So use the symbol name explicitly. Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2022-10-20 11:26:42 +02:00
PROVIDE(__efistub__gzdata_size =
ABSOLUTE(__efistub__gzdata_end - __efistub__gzdata_start));
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>
2022-05-02 01:08:16 +02:00
efi: Fix .data section size calculations when .sbat is present Commit 0f9a1739dd0e ("efi: zboot specific mechanism for embedding SBAT section") neglected to adjust the sizes of the .data section when CONFIG_EFI_SBAT_FILE is set. As the result, the produced PE binary is incorrect and some tools complain about it. E.g. 'sbsign' reports: # sbsign --key my.key --cert my.crt arch/arm64/boot/vmlinuz.efi warning: file-aligned section .data extends beyond end of file warning: checksum areas are greater than image size. Invalid section table? Note, '__data_size' is also used in the PE optional header and it is not entirely clear whether .sbat needs to be accounted as part of SizeOfInitializedData or not. As the header seems to be unused by the real world firmware, keeping the field equal to __data_size. Fixes: 0f9a1739dd0e ("efi: zboot specific mechanism for embedding SBAT section") Reported-by: Heinrich Schuchardt <heinrich.schuchardt@gmx.de> Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2025-06-20 13:16:07 +02:00
PROVIDE(__data_rawsize = ABSOLUTE(_edata - _data));
PROVIDE(__data_size = ABSOLUTE(_end - _data));
efi: zboot specific mechanism for embedding SBAT section SBAT is a mechanism which improves SecureBoot revocations of UEFI binaries by introducing a generation-based technique. Compromised or vulnerable UEFI binaries can be prevented from booting by bumping the minimal required generation for the specific component in the bootloader. More information on the SBAT can be obtained here: https://github.com/rhboot/shim/blob/main/SBAT.md Upstream Linux kernel does not currently participate in any way in SBAT as there's no existing policy in how SBAT generation number should be defined. Keep the status quo and provide a mechanism for distro vendors and anyone else who signs their kernel for SecureBoot to include their own SBAT data. This leaves the decision on the policy to the vendor. Basically, each distro implementing SecureBoot today, will have an option to inject their own SBAT data during kernel build and before it gets signed by their SecureBoot CA. Different distro do not need to agree on the common SBAT component names or generation numbers as each distro ships its own 'shim' with their own 'vendor_cert'/'vendor_db' Implement support for embedding SBAT data for architectures using zboot (arm64, loongarch, riscv). Put '.sbat' section in between '.data' and '.text' as the former also covers '.bss' and thus must be the last one. Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2025-05-13 14:58:07 +02:00
PROVIDE(__sbat_size = ABSOLUTE(_esbat - _sbat));
Reference in a new issue Copy permalink