Revision tags: v6.6.25, v6.6.24, v6.6.23, v6.6.16, v6.6.15 |
|
#
0e7ca435 |
| 30-Jan-2024 |
Ard Biesheuvel <ardb@kernel.org> |
x86/efistub: Avoid placing the kernel below LOAD_PHYSICAL_ADDR
[ Upstream commit 2f77465b05b1270c832b5e2ee27037672ad2a10a ]
The EFI stub's kernel placement logic randomizes the physical placement o
x86/efistub: Avoid placing the kernel below LOAD_PHYSICAL_ADDR
[ Upstream commit 2f77465b05b1270c832b5e2ee27037672ad2a10a ]
The EFI stub's kernel placement logic randomizes the physical placement of the kernel by taking all available memory into account, and picking a region at random, based on a random seed.
When KASLR is disabled, this seed is set to 0x0, and this results in the lowest available region of memory to be selected for loading the kernel, even if this is below LOAD_PHYSICAL_ADDR. Some of this memory is typically reserved for the GFP_DMA region, to accommodate masters that can only access the first 16 MiB of system memory.
Even if such devices are rare these days, we may still end up with a warning in the kernel log, as reported by Tom:
swapper/0: page allocation failure: order:10, mode:0xcc1(GFP_KERNEL|GFP_DMA), nodemask=(null),cpuset=/,mems_allowed=0
Fix this by tweaking the random allocation logic to accept a low bound on the placement, and set it to LOAD_PHYSICAL_ADDR.
Fixes: a1b87d54f4e4 ("x86/efistub: Avoid legacy decompressor when doing EFI boot") Reported-by: Tom Englund <tomenglund26@gmail.com> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218404 Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
Revision tags: 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 |
|
#
bc5ddcef |
| 07-Aug-2023 |
Ard Biesheuvel <ardb@kernel.org> |
efi/libstub: Add limit argument to efi_random_alloc()
x86 will need to limit the kernel memory allocation to the lowest 512 MiB of memory, to match the behavior of the existing bare metal KASLR phys
efi/libstub: Add limit argument to efi_random_alloc()
x86 will need to limit the kernel memory allocation to the lowest 512 MiB of memory, to match the behavior of the existing bare metal KASLR physical randomization logic. So in preparation for that, add a limit parameter to efi_random_alloc() and wire it up.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://lore.kernel.org/r/20230807162720.545787-22-ardb@kernel.org
show more ...
|
Revision tags: 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, 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 ...
|
#
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 |
|
#
fc3608aa |
| 21-Mar-2023 |
Ard Biesheuvel <ardb@kernel.org> |
efi/libstub: Use relocated version of kernel's struct screen_info
In some cases, we expose the kernel's struct screen_info to the EFI stub directly, so it gets populated before even entering the ker
efi/libstub: Use relocated version of kernel's struct screen_info
In some cases, we expose the kernel's struct screen_info to the EFI stub directly, so it gets populated before even entering the kernel. This means the early console is available as soon as the early param parsing happens, which is nice. It also means we need two different ways to pass this information, as this trick only works if the EFI stub is baked into the core kernel image, which is not always the case.
Huacai reports that the preparatory refactoring that was needed to implement this alternative method for zboot resulted in a non-functional efifb earlycon for other cases as well, due to the reordering of the kernel image relocation with the population of the screen_info struct, and the latter now takes place after copying the image to its new location, which means we copy the old, uninitialized state.
So let's ensure that the same-image version of alloc_screen_info() produces the correct screen_info pointer, by taking the displacement of the loaded image into account.
Reported-by: Huacai Chen <chenhuacai@loongson.cn> Tested-by: Huacai Chen <chenhuacai@loongson.cn> Link: https://lore.kernel.org/linux-efi/20230310021749.921041-1-chenhuacai@loongson.cn/ Fixes: 42c8ea3dca094ab8 ("efi: libstub: Factor out EFI stub entrypoint into separate file") 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 |
|
#
ace013a5 |
| 30-Jan-2023 |
Ard Biesheuvel <ardb@kernel.org> |
efi: zboot: Use EFI protocol to remap code/data with the right attributes
Use the recently introduced EFI_MEMORY_ATTRIBUTES_PROTOCOL in the zboot implementation to set the right attributes for the c
efi: zboot: Use EFI protocol to remap code/data with the right attributes
Use the recently introduced EFI_MEMORY_ATTRIBUTES_PROTOCOL in the zboot implementation to set the right attributes for the code and data sections of the decompressed image, i.e., EFI_MEMORY_RO for code and EFI_MEMORY_XP for data.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
show more ...
|
Revision tags: 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 |
|
#
c51e97e7 |
| 13-Oct-2022 |
Ard Biesheuvel <ardb@kernel.org> |
efi: libstub: Merge zboot decompressor with the ordinary stub
Even though our EFI zboot decompressor is pedantically spec compliant and idiomatic for EFI image loaders, calling LoadImage() and Start
efi: libstub: Merge zboot decompressor with the ordinary stub
Even though our EFI zboot decompressor is pedantically spec compliant and idiomatic for EFI image loaders, calling LoadImage() and StartImage() for the nested image is a bit of a burden. Not only does it create workflow issues for the distros (as both the inner and outer PE/COFF images need to be signed for secure boot), it also copies the image around in memory numerous times: - first, the image is decompressed into a buffer; - the buffer is consumed by LoadImage(), which copies the sections into a newly allocated memory region to hold the executable image; - once the EFI stub is invoked by StartImage(), it will also move the image in memory in case of KASLR, mirrored memory or if the image must execute from a certain a priori defined address.
There are only two EFI spec compliant ways to load code into memory and execute it: - use LoadImage() and StartImage(), - call ExitBootServices() and take ownership of the entire system, after which anything goes.
Given that the EFI zboot decompressor always invokes the EFI stub, and given that both are built from the same set of objects, let's merge the two, so that we can avoid LoadImage()/StartImage but still load our image into memory without breaking the above rules.
This also means we can decompress the image directly into its final location, which could be randomized or meet other platform specific constraints that LoadImage() does not know how to adhere to. It also means that, even if the encapsulated image still has the EFI stub incorporated as well, it does not need to be signed for secure boot when wrapping it in the EFI zboot decompressor.
In the future, we might decide to retire the EFI stub attached to the decompressed image, but for the time being, they can happily coexist.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
show more ...
|
Revision tags: v5.15.73, v6.0.1 |
|
#
2e6fa86f |
| 11-Oct-2022 |
Ard Biesheuvel <ardb@kernel.org> |
efi: libstub: Enable efi_printk() in zboot decompressor
Split the efi_printk() routine into its own source file, and provide local implementations of strlen() and strnlen() so that the standalone zb
efi: libstub: Enable efi_printk() in zboot decompressor
Split the efi_printk() routine into its own source file, and provide local implementations of strlen() and strnlen() so that the standalone zboot app can efi_err and efi_info etc.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
show more ...
|
#
52dce39c |
| 11-Oct-2022 |
Ard Biesheuvel <ardb@kernel.org> |
efi: libstub: Clone memcmp() into the stub
We will no longer be able to call into the kernel image once we merge the decompressor with the EFI stub, so we need our own implementation of memcmp(). Le
efi: libstub: Clone memcmp() into the stub
We will no longer be able to call into the kernel image once we merge the decompressor with the EFI stub, so we need our own implementation of memcmp(). Let's add the one from lib/string.c and simplify it.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
show more ...
|
Revision tags: v5.15.72, v6.0, v5.15.71, v5.15.70 |
|
#
3c6edd90 |
| 22-Sep-2022 |
Ard Biesheuvel <ardb@kernel.org> |
efi: zboot: create MemoryMapped() device path for the parent if needed
LoadImage() is supposed to install an instance of the protocol EFI_LOADED_IMAGE_DEVICE_PATH_PROTOCOL onto the loaded image's ha
efi: zboot: create MemoryMapped() device path for the parent if needed
LoadImage() is supposed to install an instance of the protocol EFI_LOADED_IMAGE_DEVICE_PATH_PROTOCOL onto the loaded image's handle so that the program can figure out where it was loaded from. The reference implementation even does this (with a NULL protocol pointer) if the call to LoadImage() used the source buffer and size arguments, and passed NULL for the image device path. Hand rolled implementations of LoadImage may behave differently, though, and so it is better to tolerate situations where the protocol is missing. And actually, concatenating an Offset() node to a NULL device path (as we do currently) is not great either.
So in cases where the protocol is absent, or when it points to NULL, construct a MemoryMapped() device node as the base node that describes the parent image's footprint in memory.
Cc: Daan De Meyer <daandemeyer@fb.com> Cc: Jeremy Linton <jeremy.linton@arm.com> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
show more ...
|
Revision tags: 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 ...
|