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, v6.1.29, v6.1.28, v6.1.27, v6.1.26, v6.3, v6.1.25, 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, 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 |
|
#
42c8ea3d |
| 12-Oct-2022 |
Ard Biesheuvel <ardb@kernel.org> |
efi: libstub: Factor out EFI stub entrypoint into separate file
In preparation for allowing the EFI zboot decompressor to reuse most of the EFI stub machinery, factor out the actual EFI PE/COFF entr
efi: libstub: Factor out EFI stub entrypoint into separate file
In preparation for allowing the EFI zboot decompressor to reuse most of the EFI stub machinery, factor out the actual EFI PE/COFF entrypoint into a separate file.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
show more ...
|
Revision tags: v5.15.73, v6.0.1 |
|
#
732ea9db |
| 11-Oct-2022 |
Ard Biesheuvel <ardb@kernel.org> |
efi: libstub: Move screen_info handling to common code
Currently, arm64, RISC-V and LoongArch rely on the fact that struct screen_info can be accessed directly, due to the fact that the EFI stub and
efi: libstub: Move screen_info handling to common code
Currently, arm64, RISC-V and LoongArch rely on the fact that struct screen_info can be accessed directly, due to the fact that the EFI stub and the core kernel are part of the same image. This will change after a future patch, so let's ensure that the screen_info handling is able to deal with this, by adopting the arm32 approach of passing it as a configuration table. While at it, switch to ACPI reclaim memory to hold the screen_info data, which is more appropriate for this kind of allocation.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
show more ...
|
#
48b9491c |
| 11-Oct-2022 |
Ard Biesheuvel <ardb@kernel.org> |
efi: libstub: Drop handling of EFI properties table
The EFI properties table was a short lived experiment that never saw the light of day on non-x86 (if at all) so let's drop the handling of it.
Si
efi: libstub: Drop handling of EFI properties table
The EFI properties table was a short lived experiment that never saw the light of day on non-x86 (if at all) so let's drop the handling of it.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
show more ...
|
#
085e2ff9 |
| 11-Oct-2022 |
Ard Biesheuvel <ardb@kernel.org> |
efi: libstub: Drop randomization of runtime memory map
Randomizing the UEFI runtime memory map requires the use of the SetVirtualAddressMap() EFI boot service, which we prefer to avoid. So let's dro
efi: libstub: Drop randomization of runtime memory map
Randomizing the UEFI runtime memory map requires the use of the SetVirtualAddressMap() EFI boot service, which we prefer to avoid. So let's drop randomization, which was already problematic in combination with hibernation, which means that distro kernels never enabled it in the first place.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
show more ...
|
Revision tags: v5.15.72, v6.0, v5.15.71, v5.15.70, v5.15.69 |
|
#
04419e8a |
| 16-Sep-2022 |
Ard Biesheuvel <ardb@kernel.org> |
efi: libstub: fix up the last remaining open coded boot service call
We use a macro efi_bs_call() to call boot services, which is more concise, and on x86, it encapsulates the mixed mode handling. T
efi: libstub: fix up the last remaining open coded boot service call
We use a macro efi_bs_call() to call boot services, which is more concise, and on x86, it encapsulates the mixed mode handling. This code does not run in mixed mode, but let's switch to the macro for general tidiness.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
show more ...
|
#
4fc8e738 |
| 16-Sep-2022 |
Ard Biesheuvel <ardb@kernel.org> |
efi: libstub: remove DT dependency from generic stub
Refactor the generic EFI stub entry code so that all the dependencies on device tree are abstracted and hidden behind a generic efi_boot_kernel()
efi: libstub: remove DT dependency from generic stub
Refactor the generic EFI stub entry code so that all the dependencies on device tree are abstracted and hidden behind a generic efi_boot_kernel() routine that can also be implemented in other ways. This allows users of the generic stub to avoid using FDT for passing information to the core kernel.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
show more ...
|
#
f4dc7fff |
| 16-Sep-2022 |
Ard Biesheuvel <ardb@kernel.org> |
efi: libstub: unify initrd loading between architectures
Use a EFI configuration table to pass the initrd to the core kernel, instead of per-arch methods. This cleans up the code considerably, and s
efi: libstub: unify initrd loading between architectures
Use a EFI configuration table to pass the initrd to the core kernel, instead of per-arch methods. This cleans up the code considerably, and should make it easier for architectures to get rid of their reliance on DT for doing EFI boot in the future.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
show more ...
|
#
f80d2604 |
| 15-Sep-2022 |
Ard Biesheuvel <ardb@kernel.org> |
efi: libstub: avoid efi_get_memory_map() for allocating the virt map
The virt map is a set of efi_memory_desc_t descriptors that are passed to SetVirtualAddressMap() to inform the firmware about the
efi: libstub: avoid efi_get_memory_map() for allocating the virt map
The virt map is a set of efi_memory_desc_t descriptors that are passed to SetVirtualAddressMap() to inform the firmware about the desired virtual mapping of the regions marked as EFI_MEMORY_RUNTIME. The only reason we currently call the efi_get_memory_map() helper is that it gives us an allocation that is guaranteed to be of sufficient size. However, efi_get_memory_map() has grown some additional complexity over the years, and today, we're actually better off calling the EFI boot service directly with a zero size, which tells us how much memory should be enough for the virt map.
While at it, avoid creating the VA map allocation if we will not be using it anyway, i.e., if efi_novamap is true.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
show more ...
|
Revision tags: 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 |
|
#
514377d8 |
| 06-May-2022 |
Ard Biesheuvel <ardb@kernel.org> |
efi/libstub: move efi_system_table global var into separate object
To avoid pulling in the wrong object when using the libstub static library to build the decompressor, define efi_system_table in a
efi/libstub: move efi_system_table global var into separate object
To avoid pulling in the wrong object when using the libstub static library to build the decompressor, define efi_system_table in a separate compilation unit.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
show more ...
|
#
ead384d9 |
| 19-Aug-2022 |
Huacai Chen <chenhuacai@loongson.cn> |
efi/loongarch: Add efistub booting support
This patch adds efistub booting support, which is the standard UEFI boot protocol for LoongArch to use.
We use generic efistub, which means we can pass bo
efi/loongarch: Add efistub booting support
This patch adds efistub booting support, which is the standard UEFI boot protocol for LoongArch to use.
We use generic efistub, which means we can pass boot information (i.e., system table, memory map, kernel command line, initrd) via a light FDT and drop a lot of non-standard code.
We use a flat mapping to map the efi runtime in the kernel's address space. In efi, VA = PA; in kernel, VA = PA + PAGE_OFFSET. As a result, flat mapping is not identity mapping, SetVirtualAddressMap() is still needed for the efi runtime.
Tested-by: Xi Ruoyao <xry111@xry111.site> Signed-off-by: Huacai Chen <chenhuacai@loongson.cn> [ardb: change fpic to fpie as suggested by Xi Ruoyao] Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
show more ...
|
Revision tags: v5.15.37, v5.15.36, v5.15.35, v5.15.34, v5.15.33, v5.15.32, v5.15.31, v5.17 |
|
#
416a9f84 |
| 19-Mar-2022 |
Ard Biesheuvel <ardb@kernel.org> |
efi: libstub: pass image handle to handle_kernel_image()
In a future patch, arm64's implementation of handle_kernel_image() will omit randomizing the placement of the kernel if the load address was
efi: libstub: pass image handle to handle_kernel_image()
In a future patch, arm64's implementation of handle_kernel_image() will omit randomizing the placement of the kernel if the load address was chosen randomly by the loader. In order to do this, it needs to locate a protocol on the image handle, so pass it to handle_kernel_image().
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
show more ...
|
Revision tags: v5.15.30, v5.15.29, v5.15.28, v5.15.27, v5.15.26, v5.15.25, v5.15.24, v5.15.23, v5.15.22, v5.15.21, v5.15.20, v5.15.19, v5.15.18, v5.15.17, v5.4.173, v5.15.16, v5.15.15, v5.16, v5.15.10, v5.15.9, v5.15.8, v5.15.7 |
|
#
e8a62cc2 |
| 06-Dec-2021 |
Alexandre Ghiti <alexandre.ghiti@canonical.com> |
riscv: Implement sv48 support
By adding a new 4th level of page table, give the possibility to 64bit kernel to address 2^48 bytes of virtual address: in practice, that offers 128TB of virtual addres
riscv: Implement sv48 support
By adding a new 4th level of page table, give the possibility to 64bit kernel to address 2^48 bytes of virtual address: in practice, that offers 128TB of virtual address space to userspace and allows up to 64TB of physical memory.
If the underlying hardware does not support sv48, we will automatically fallback to a standard 3-level page table by folding the new PUD level into PGDIR level. In order to detect HW capabilities at runtime, we use SATP feature that ignores writes with an unsupported mode.
Signed-off-by: Alexandre Ghiti <alexandre.ghiti@canonical.com> Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
show more ...
|
Revision tags: v5.15.6, v5.15.5, v5.15.4 |
|
#
20287d56 |
| 19-Nov-2021 |
Ard Biesheuvel <ardb@kernel.org> |
efi/libstub: consolidate initrd handling across architectures
Before adding TPM measurement of the initrd contents, refactor the initrd handling slightly to be more self-contained and consistent.
S
efi/libstub: consolidate initrd handling across architectures
Before adding TPM measurement of the initrd contents, refactor the initrd handling slightly to be more self-contained and consistent.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Link: https://lore.kernel.org/r/20211119114745.1560453-4-ilias.apalodimas@linaro.org Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
show more ...
|
Revision tags: v5.15.3, v5.15.2, v5.15.1, v5.15, v5.14.14, v5.14.13, v5.14.12, v5.14.11, v5.14.10, v5.14.9, v5.14.8, v5.14.7, v5.14.6, v5.10.67, v5.10.66, v5.14.5, v5.14.4, v5.10.65, v5.14.3, v5.10.64, v5.14.2, v5.10.63, v5.14.1, v5.10.62, v5.14, v5.10.61, v5.10.60, v5.10.53, v5.10.52, v5.10.51, v5.10.50, v5.10.49, v5.13, v5.10.46, v5.10.43, v5.10.42, v5.10.41, v5.10.40, v5.10.39, v5.4.119, v5.10.36, v5.10.35, v5.10.34, v5.4.116, v5.10.33, v5.12, v5.10.32, v5.10.31, v5.10.30, v5.10.27, v5.10.26, v5.10.25, v5.10.24, v5.10.23, v5.10.22, v5.10.21 |
|
#
9e9888a0 |
| 05-Mar-2021 |
Ard Biesheuvel <ardb@kernel.org> |
efi: stub: omit SetVirtualAddressMap() if marked unsupported in RT_PROP table
The EFI_RT_PROPERTIES_TABLE contains a mask of runtime services that are available after ExitBootServices(). This mostly
efi: stub: omit SetVirtualAddressMap() if marked unsupported in RT_PROP table
The EFI_RT_PROPERTIES_TABLE contains a mask of runtime services that are available after ExitBootServices(). This mostly does not concern the EFI stub at all, given that it runs before that. However, there is one call that is made at runtime, which is the call to SetVirtualAddressMap() (which is not even callable at boot time to begin with)
So add the missing handling of the RT_PROP table to ensure that we only call SetVirtualAddressMap() if it is not being advertised as unsupported by the firmware.
Cc: <stable@vger.kernel.org> # v5.10+ Tested-by: Shawn Guo <shawn.guo@linaro.org> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
show more ...
|
Revision tags: v5.10.20, v5.10.19, v5.4.101, v5.10.18, v5.10.17, v5.11, v5.10.16, v5.10.15, v5.10.14, v5.10 |
|
#
54649911 |
| 29-Oct-2020 |
Ard Biesheuvel <ardb@kernel.org> |
efi: stub: get rid of efi_get_max_fdt_addr()
Now that ARM started following the example of arm64 and RISC-V, and no longer imposes any restrictions on the placement of the FDT in memory at boot, we
efi: stub: get rid of efi_get_max_fdt_addr()
Now that ARM started following the example of arm64 and RISC-V, and no longer imposes any restrictions on the placement of the FDT in memory at boot, we no longer need per-arch implementations of efi_get_max_fdt_addr() to factor out the differences. So get rid of it.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Reviewed-by: Atish Patra <atish.patra@wdc.com> Link: https://lore.kernel.org/r/20201029134901.9773-1-ardb@kernel.org
show more ...
|
#
8571c664 |
| 05-Mar-2021 |
Ard Biesheuvel <ardb@kernel.org> |
efi: stub: omit SetVirtualAddressMap() if marked unsupported in RT_PROP table
commit 9e9888a0fe97b9501a40f717225d2bef7100a2c1 upstream.
The EFI_RT_PROPERTIES_TABLE contains a mask of runtime servic
efi: stub: omit SetVirtualAddressMap() if marked unsupported in RT_PROP table
commit 9e9888a0fe97b9501a40f717225d2bef7100a2c1 upstream.
The EFI_RT_PROPERTIES_TABLE contains a mask of runtime services that are available after ExitBootServices(). This mostly does not concern the EFI stub at all, given that it runs before that. However, there is one call that is made at runtime, which is the call to SetVirtualAddressMap() (which is not even callable at boot time to begin with)
So add the missing handling of the RT_PROP table to ensure that we only call SetVirtualAddressMap() if it is not being advertised as unsupported by the firmware.
Cc: <stable@vger.kernel.org> # v5.10+ Tested-by: Shawn Guo <shawn.guo@linaro.org> Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
Revision tags: v5.8.17, v5.8.16, v5.8.15, v5.9, v5.8.14, v5.8.13, v5.8.12, v5.8.11 |
|
#
b91540d5 |
| 17-Sep-2020 |
Atish Patra <atish.patra@wdc.com> |
RISC-V: Add EFI runtime services
This patch adds EFI runtime service support for RISC-V.
Signed-off-by: Atish Patra <atish.patra@wdc.com> [ardb: - Remove the page check] Signed-off-by: Ard Biesheuv
RISC-V: Add EFI runtime services
This patch adds EFI runtime service support for RISC-V.
Signed-off-by: Atish Patra <atish.patra@wdc.com> [ardb: - Remove the page check] Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Acked-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com>
show more ...
|
Revision tags: v5.8.10, v5.8.9, v5.8.8 |
|
#
762cd288 |
| 09-Sep-2020 |
Ard Biesheuvel <ardb@kernel.org> |
efi/libstub: arm32: Use low allocation for the uncompressed kernel
Before commit
d0f9ca9be11f25ef ("ARM: decompressor: run decompressor in place if loaded via UEFI")
we were rather limited in th
efi/libstub: arm32: Use low allocation for the uncompressed kernel
Before commit
d0f9ca9be11f25ef ("ARM: decompressor: run decompressor in place if loaded via UEFI")
we were rather limited in the choice of base address for the uncompressed kernel, as we were relying on the logic in the decompressor that blindly rounds down the decompressor execution address to the next multiple of 128 MiB, and decompresses the kernel there. For this reason, we have a lot of complicated memory region handling code, to ensure that this memory window is available, even though it could be occupied by reserved regions or other allocations that may or may not collide with the uncompressed image.
Today, we simply pass the target address for the decompressed image to the decompressor directly, and so we can choose a suitable window just by finding a 16 MiB aligned region, while taking TEXT_OFFSET and the region for the swapper page tables into account.
So let's get rid of the complicated logic, and instead, use the existing bottom up allocation routine to allocate a suitable window as low as possible, and carve out a memory region that has the right properties.
Note that this removes any dependencies on the 'dram_base' argument to handle_kernel_image(), and so this is removed as well. Given that this was the only remaining use of dram_base, the code that produces it is removed entirely as well.
Reviewed-by: Maxim Uvarov <maxim.uvarov@linaro.org> Tested-by: Maxim Uvarov <maxim.uvarov@linaro.org> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
show more ...
|
#
6208857b |
| 10-Sep-2020 |
Ard Biesheuvel <ardb@kernel.org> |
efi/libstub: arm32: Base FDT and initrd placement on image address
The way we use the base of DRAM in the EFI stub is problematic as it is ill defined what the base of DRAM actually means. There are
efi/libstub: arm32: Base FDT and initrd placement on image address
The way we use the base of DRAM in the EFI stub is problematic as it is ill defined what the base of DRAM actually means. There are some restrictions on the placement of FDT and initrd which are defined in terms of dram_base, but given that the placement of the kernel in memory is what defines these boundaries (as on ARM, this is where the linear region starts), it is better to use the image address in these cases, and disregard dram_base altogether.
Reviewed-by: Maxim Uvarov <maxim.uvarov@linaro.org> Tested-by: Maxim Uvarov <maxim.uvarov@linaro.org> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
show more ...
|
Revision tags: v5.8.7, v5.8.6, v5.4.62, v5.8.5, v5.8.4, v5.4.61, v5.8.3, v5.4.60, v5.8.2, v5.4.59, v5.8.1, v5.4.58, v5.4.57, v5.4.56, v5.8, v5.7.12, v5.4.55, v5.7.11, v5.4.54, v5.7.10, v5.4.53, v5.4.52, v5.7.9, v5.7.8, v5.4.51 |
|
#
3230d95c |
| 06-Jul-2020 |
Atish Patra <atish.patra@wdc.com> |
efi/libstub: Move the function prototypes to header file
The prototype of the functions handle_kernel_image & efi_enter_kernel are defined in efi-stub.c which may result in a compiler warnings if -W
efi/libstub: Move the function prototypes to header file
The prototype of the functions handle_kernel_image & efi_enter_kernel are defined in efi-stub.c which may result in a compiler warnings if -Wmissing-prototypes is set in gcc compiler.
Move the prototype to efistub.h to make the compiler happy.
Signed-off-by: Atish Patra <atish.patra@wdc.com> Link: https://lore.kernel.org/r/20200706172609.25965-2-atish.patra@wdc.com Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
show more ...
|
Revision tags: v5.4.50, v5.7.7, v5.4.49, v5.7.6, v5.7.5, v5.4.48, v5.7.4, v5.7.3, v5.4.47, v5.4.46, v5.7.2 |
|
#
2a55280a |
| 07-Jun-2020 |
Ard Biesheuvel <ardb@kernel.org> |
efi/libstub: arm: Print CPU boot mode and MMU state at boot
On 32-bit ARM, we may boot at HYP mode, or with the MMU and caches off (or both), even though the EFI spec does not actually support this.
efi/libstub: arm: Print CPU boot mode and MMU state at boot
On 32-bit ARM, we may boot at HYP mode, or with the MMU and caches off (or both), even though the EFI spec does not actually support this. While booting at HYP mode is something we might tolerate, fiddling with the caches is a more serious issue, as disabling the caches is tricky to do safely from C code, and running without the Dcache makes it impossible to support unaligned memory accesses, which is another explicit requirement imposed by the EFI spec.
So take note of the CPU mode and MMU state in the EFI stub diagnostic output so that we can easily diagnose any issues that may arise from this. E.g.,
EFI stub: Entering in SVC mode with MMU enabled
Also, capture the CPSR and SCTLR system register values at EFI stub entry, and after ExitBootServices() returns, and check whether the MMU and Dcache were disabled at any point. If this is the case, a diagnostic message like the following will be emitted:
efi: [Firmware Bug]: EFI stub was entered with MMU and Dcache disabled, please fix your firmware! efi: CPSR at EFI stub entry : 0x600001d3 efi: SCTLR at EFI stub entry : 0x00c51838 efi: CPSR after ExitBootServices() : 0x600001d3 efi: SCTLR after ExitBootServices(): 0x00c50838
Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Reviewed-by: Leif Lindholm <leif@nuviainc.com>
show more ...
|
Revision tags: v5.4.45, v5.7.1, v5.4.44, v5.7, v5.4.43 |
|
#
6e99d321 |
| 23-May-2020 |
Ard Biesheuvel <ardb@kernel.org> |
efi/libstub: Add missing prototype for PE/COFF entry point
Fix a missing prototype warning by adding a forward declaration for the PE/COFF entrypoint, and while at it, align the function name betwee
efi/libstub: Add missing prototype for PE/COFF entry point
Fix a missing prototype warning by adding a forward declaration for the PE/COFF entrypoint, and while at it, align the function name between the x86 and ARM versions of the stub.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
show more ...
|
Revision tags: v5.4.42 |
|
#
27cd5511 |
| 19-May-2020 |
Ard Biesheuvel <ardb@kernel.org> |
efi/libstub: Use pool allocation for the command line
Now that we removed the memory limit for the allocation of the command line, there is no longer a need to use the page based allocator so switch
efi/libstub: Use pool allocation for the command line
Now that we removed the memory limit for the allocation of the command line, there is no longer a need to use the page based allocator so switch to a pool allocation instead.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
show more ...
|
Revision tags: v5.4.41, v5.4.40, v5.4.39, v5.4.38, v5.4.37 |
|
#
055042be |
| 30-Apr-2020 |
Arvind Sankar <nivedita@alum.mit.edu> |
efi/libstub: Check return value of efi_parse_options
efi_parse_options can fail if it is unable to allocate space for a copy of the command line. Check the return value to make sure it succeeded.
S
efi/libstub: Check return value of efi_parse_options
efi_parse_options can fail if it is unable to allocate space for a copy of the command line. Check the return value to make sure it succeeded.
Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu> Link: https://lore.kernel.org/r/20200430182843.2510180-12-nivedita@alum.mit.edu Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
show more ...
|