aboutsummaryrefslogtreecommitdiff
path: root/drivers/firmware/efi/libstub
AgeCommit message (Collapse)AuthorFilesLines
2020-05-01efi/tpm: Use efi_err for error messagesArvind Sankar1-1/+1
Use efi_err instead of bare efi_printk for error messages. Signed-off-by: Arvind Sankar <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ard Biesheuvel <[email protected]>
2020-05-01efi/gop: Use efi_err for error messagesArvind Sankar1-5/+5
Use efi_err instead of bare efi_printk for error messages. Signed-off-by: Arvind Sankar <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ard Biesheuvel <[email protected]>
2020-05-01efi/x86: Use efi_err for error messagesArvind Sankar1-12/+12
Use efi_err instead of bare efi_printk for error messages. Signed-off-by: Arvind Sankar <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ard Biesheuvel <[email protected]>
2020-05-01efi/libstub: Move pr_efi/pr_efi_err into efi namespaceArvind Sankar9-52/+52
Rename pr_efi to efi_info and pr_efi_err to efi_err to make it more obvious that they are part of the EFI stub and not generic printk infra. Suggested-by: Joe Perches <[email protected]> Signed-off-by: Arvind Sankar <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ard Biesheuvel <[email protected]>
2020-05-01efi/libstub: Add a helper function to split 64-bit valuesArvind Sankar3-22/+23
In several places 64-bit values need to be split up into two 32-bit fields, in order to be backward-compatible with the old 32-bit ABIs. Instead of open-coding this, add a helper function to set a 64-bit value as two 32-bit fields. Signed-off-by: Arvind Sankar <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ard Biesheuvel <[email protected]>
2020-05-01efi/x86: Use correct size for boot_paramsArvind Sankar1-3/+4
struct boot_params is only 4096 bytes, not 16384. Fix this by using sizeof(struct boot_params) instead of hardcoding the incorrect value. Signed-off-by: Arvind Sankar <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ard Biesheuvel <[email protected]>
2020-04-30efi/libstub: Avoid returning uninitialized data from setup_graphics()Heinrich Schuchardt1-1/+5
Currently, setup_graphics() ignores the return value of efi_setup_gop(). As AllocatePool() does not zero out memory, the screen information table will contain uninitialized data in this case. We should free the screen information table if efi_setup_gop() returns an error code. Signed-off-by: Heinrich Schuchardt <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ard Biesheuvel <[email protected]>
2020-04-24efi/libstub/x86: Avoid getter function for efi_is64Ard Biesheuvel1-8/+0
We no longer need to take special care when using global variables in the EFI stub, so switch to a simple symbol reference for efi_is64. Signed-off-by: Ard Biesheuvel <[email protected]>
2020-04-24efi/libstub: Drop __pure getters for EFI stub optionsArd Biesheuvel7-39/+20
The practice of using __pure getter functions to access global variables in the EFI stub dates back to the time when we had to carefully prevent GOT entries from being emitted, because we could not rely on the toolchain to do this for us. Today, we use the hidden visibility pragma for all EFI stub source files, which now all live in the same subdirectory, and we apply a sanity check on the objects, so we can get rid of these getter functions and simply refer to global data objects directly. So switch over the remaining boolean variables carrying options set on the kernel command line. Signed-off-by: Ard Biesheuvel <[email protected]>
2020-04-24efi/libstub: Drop __pure getter for efi_system_tableArd Biesheuvel5-32/+22
The practice of using __pure getter functions to access global variables in the EFI stub dates back to the time when we had to carefully prevent GOT entries from being emitted, because we could not rely on the toolchain to do this for us. Today, we use the hidden visibility pragma for all EFI stub source files, which now all live in the same subdirectory, and we apply a sanity check on the objects, so we can get rid of these getter functions and simply refer to global data objects directly. Start with efi_system_table(), and convert it into a global variable. While at it, make it a pointer-to-const, because we can. Signed-off-by: Ard Biesheuvel <[email protected]>
2020-04-24efi: Kill __efistub_globalArvind Sankar5-14/+11
Now that both arm and x86 are using the linker script to place the EFI stub's global variables in the correct section, remove __efistub_global. Signed-off-by: Arvind Sankar <[email protected]> Reviewed-by: Ard Biesheuvel <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ard Biesheuvel <[email protected]>
2020-04-24efi/x86: Remove __efistub_global and add relocation checkArvind Sankar2-15/+21
Instead of using __efistub_global to force variables into the .data section, leave them in the .bss but pull the EFI stub's .bss section into .data in the linker script for the compressed kernel. Add relocation checking for x86 as well to catch non-PC-relative relocations that require runtime processing, since the EFI stub does not do any runtime relocation processing. This will catch, for example, data relocations created by static initializers of pointers. Signed-off-by: Arvind Sankar <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ard Biesheuvel <[email protected]>
2020-04-24efi/arm: Remove __efistub_global annotationArvind Sankar2-4/+5
Instead of using __efistub_global to force variables into the .data section, leave them in the .bss but pull the EFI stub's .bss section into .data in the linker script for the compressed kernel. Signed-off-by: Arvind Sankar <[email protected]> Reviewed-by: Ard Biesheuvel <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ard Biesheuvel <[email protected]>
2020-04-24efi/libstub: Move efi_relocate_kernel() into separate source fileArd Biesheuvel4-184/+175
Move efi_relocate_kernel() into a separate source file, so that it only gets pulled into builds for architectures that use it. Since efi_relocate_kernel() is the only user of efi_low_alloc(), let's move that over as well. Signed-off-by: Ard Biesheuvel <[email protected]>
2020-04-24efi/libstub/arm64: Switch to ordinary page allocator for kernel imageArd Biesheuvel1-2/+2
It is no longer necessary to locate the kernel as low as possible in physical memory, and so we can switch from efi_low_alloc() [which is a rather nasty concoction on top of GetMemoryMap()] to a new helper called efi_allocate_pages_aligned(), which simply rounds up the size to account for the alignment, and frees the misaligned pages again. So considering that the kernel can live anywhere in the physical address space, as long as its alignment requirements are met, let's switch to efi_allocate_pages_aligned() to allocate the pages. Signed-off-by: Ard Biesheuvel <[email protected]>
2020-04-24efi/libstub: Add API function to allocate aligned memoryArd Biesheuvel4-17/+71
Break out the code to create an aligned page allocation from mem.c and move it into a function efi_allocate_pages_aligned() in alignedmem.c. Update efi_allocate_pages() to invoke it unless the minimum alignment equals the EFI page size (4 KB), in which case the ordinary page allocator is sufficient. This way, efi_allocate_pages_aligned() will only be pulled into the build if it is actually being used (which will be on arm64 only in the immediate future) Signed-off-by: Ard Biesheuvel <[email protected]>
2020-04-23efi/libstub/arm64: Simplify randomized loading of kernel imageArd Biesheuvel1-27/+5
The KASLR code path in the arm64 version of the EFI stub incorporates some overly complicated logic to randomly allocate a region of the right alignment: there is no need to randomize the placement of the kernel modulo 2 MiB separately from the placement of the 2 MiB aligned allocation itself - we can simply follow the same logic used by the non-randomized placement, which is to allocate at the correct alignment, and only take TEXT_OFFSET into account if it is not a round multiple of the alignment. Signed-off-by: Ard Biesheuvel <[email protected]>
2020-04-23efi/libstub/arm64: Replace 'preferred' offset with alignment checkArd Biesheuvel1-37/+25
The notion of a 'preferred' load offset for the kernel dates back to the times when the kernel's primary mapping overlapped with the linear region, and memory below it could not be used at all. Today, the arm64 kernel does not really care where it is loaded in physical memory, as long as the alignment requirements are met, and so there is no point in unconditionally moving the kernel to a new location in memory at boot. Instead, we can - check for a KASLR seed, and randomly reallocate the kernel if one is provided - otherwise, check whether the alignment requirements are met for the current placement of the kernel, and just run it in place if they are - finally, do an ordinary page allocation and reallocate the kernel to a suitably aligned buffer anywhere in memory. By the same reasoning, there is no need to take TEXT_OFFSET into account if it is a round multiple of the minimum alignment, which is the usual case for relocatable kernels with TEXT_OFFSET randomization disabled. Otherwise, it suffices to use the relative misaligment of TEXT_OFFSET when reallocating the kernel. Signed-off-by: Ard Biesheuvel <[email protected]>
2020-04-23efi/libstub/random: Increase random alloc granularityArd Biesheuvel1-1/+1
The implementation of efi_random_alloc() arbitrarily truncates the provided random seed to 16 bits, which limits the granularity of the randomly chosen allocation offset in memory. This is currently only an issue if the size of physical memory exceeds 128 GB, but going forward, we will reduce the allocation alignment to 64 KB, and this means we need to increase the granularity to ensure that the random memory allocations are distributed evenly. We will need to switch to 64-bit arithmetic for the multiplication, but this does not result in 64-bit integer intrinsic calls on ARM or on i386. Signed-off-by: Ard Biesheuvel <[email protected]>
2020-04-23efi/libstub/random: Align allocate size to EFI_ALLOC_ALIGNArd Biesheuvel1-1/+3
The EFI stub uses a per-architecture #define for the minimum base and size alignment of page allocations, which is set to 4 KB for all architecures except arm64, which uses 64 KB, to ensure that allocations can always be (un)mapped efficiently, regardless of the page size used by the kernel proper, which could be a kexec'ee The API wrappers around page based allocations assume that this alignment is always taken into account, and so efi_free() will also round up its size argument to EFI_ALLOC_ALIGN. Currently, efi_random_alloc() does not honour this alignment for the allocated size, and so freeing such an allocation may result in unrelated memory to be freed, potentially leading to issues after boot. So let's round up size in efi_random_alloc() as well. Fixes: 2ddbfc81eac84a29 ("efi: stub: add implementation of efi_random_alloc()") Signed-off-by: Ard Biesheuvel <[email protected]>
2020-04-23efi/gop: Allow automatically choosing the best modeArvind Sankar1-1/+83
Add the ability to automatically pick the highest resolution video mode (defined as the product of vertical and horizontal resolution) by using a command-line argument of the form video=efifb:auto If there are multiple modes with the highest resolution, pick one with the highest color depth. Signed-off-by: Arvind Sankar <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ard Biesheuvel <[email protected]>
2020-04-23efi/gop: Allow specifying depth as well as resolutionArvind Sankar1-5/+43
Extend the video mode argument to handle an optional color depth specification of the form video=efifb:<xres>x<yres>[-(rgb|bgr|<bpp>)] Signed-off-by: Arvind Sankar <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ard Biesheuvel <[email protected]>
2020-04-23efi/gop: Allow specifying mode by <xres>x<yres>Arvind Sankar1-1/+83
Add the ability to choose a video mode using a command-line argument of the form video=efifb:<xres>x<yres> Signed-off-by: Arvind Sankar <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ard Biesheuvel <[email protected]>
2020-04-23efi/gop: Allow specifying mode number on command lineArvind Sankar3-0/+112
Add the ability to choose a video mode for the selected gop by using a command-line argument of the form video=efifb:mode=<n> Signed-off-by: Arvind Sankar <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ard Biesheuvel <[email protected]>
2020-04-23efi/gop: Add prototypes for query_mode and set_modeArvind Sankar1-2/+4
Add prototypes and argmap for the Graphics Output Protocol's QueryMode and SetMode functions. Signed-off-by: Arvind Sankar <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ard Biesheuvel <[email protected]>
2020-04-23efi/gop: Remove unreachable code from setup_pixel_infoArvind Sankar1-40/+26
pixel_format must be one of PIXEL_RGB_RESERVED_8BIT_PER_COLOR PIXEL_BGR_RESERVED_8BIT_PER_COLOR PIXEL_BIT_MASK since we skip PIXEL_BLT_ONLY when finding a gop. Remove the redundant code and add another check in find_gop to skip any pixel formats that we don't know about, in case a later version of the UEFI spec adds one. Reformat the code a little. Signed-off-by: Arvind Sankar <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ard Biesheuvel <[email protected]>
2020-04-23efi/gop: Use helper macros for find_bitsArvind Sankar1-18/+8
Use the __ffs/__fls macros to calculate the position and size of the mask. Correct type of mask to u32 instead of unsigned long. Signed-off-by: Arvind Sankar <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ard Biesheuvel <[email protected]>
2020-04-23efi/gop: Use helper macros for populating lfb_baseArvind Sankar1-2/+2
Use the lower/upper_32_bits macros from kernel.h to initialize si->lfb_base and si->ext_lfb_base. Signed-off-by: Arvind Sankar <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ard Biesheuvel <[email protected]>
2020-04-23efi/gop: Move variable declarations into loop blockArvind Sankar1-5/+8
Declare the variables inside the block where they're used. Get rid of a couple of redundant initializers. Signed-off-by: Arvind Sankar <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ard Biesheuvel <[email protected]>
2020-04-23efi/gop: Slightly re-arrange logic of find_gopArvind Sankar1-17/+13
Small cleanup to get rid of conout_found. Signed-off-by: Arvind Sankar <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ard Biesheuvel <[email protected]>
2020-04-23efi/gop: Factor out locating the gop into a functionArvind Sankar1-6/+17
Move the loop to find a gop into its own function. Signed-off-by: Arvind Sankar <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ard Biesheuvel <[email protected]>
2020-04-23efi/gop: Get mode information outside the loopArvind Sankar1-24/+14
Move extraction of the mode information parameters outside the loop to find the gop, and eliminate some redundant variables. Signed-off-by: Arvind Sankar <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ard Biesheuvel <[email protected]>
2020-04-23efi/gop: Move check for framebuffer before con_outArvind Sankar1-5/+6
If the gop doesn't have a framebuffer, there's no point in checking for con_out support. Signed-off-by: Arvind Sankar <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ard Biesheuvel <[email protected]>
2020-04-23efi/gop: Remove redundant current_fb_baseArvind Sankar1-3/+1
current_fb_base isn't used for anything except assigning to fb_base if we locate a suitable gop. Signed-off-by: Arvind Sankar <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ard Biesheuvel <[email protected]>
2020-04-23efi/libstub/arm: Make install_memreserve_table staticZou Wei1-1/+1
Fix the following sparse warning: drivers/firmware/efi/libstub/arm-stub.c:68:6: warning: symbol 'install_memreserve_table' was not declared. Should it be static? Reported-by: Hulk Robot <[email protected]> Signed-off-by: Zou Wei <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ard Biesheuvel <[email protected]>
2020-04-23efi/libstub: unify EFI call wrappers for non-x86Ard Biesheuvel1-0/+16
We have wrappers around EFI calls so that x86 can define special versions for mixed mode, while all other architectures can use the same simple definition that just issues the call directly. In preparation for the arrival of yet another architecture that doesn't need anything special here (RISC-V), let's move the default definition into a shared header. Signed-off-by: Ard Biesheuvel <[email protected]>
2020-04-23efi/libstub: Make initrd file loader configurableArd Biesheuvel2-34/+36
Loading an initrd passed via the kernel command line is deprecated: it is limited to files that reside in the same volume as the one the kernel itself was loaded from, and we have more flexible ways to achieve the same. So make it configurable so new architectures can decide not to enable it. Signed-off-by: Ard Biesheuvel <[email protected]>
2020-04-23efi/libstub: Move arm-stub to a common fileAtish Patra2-6/+6
Most of the arm-stub code is written in an architecture independent manner. As a result, RISC-V can reuse most of the arm-stub code. Rename the arm-stub.c to efi-stub.c so that ARM, ARM64 and RISC-V can use it. This patch doesn't introduce any functional changes. Signed-off-by: Atish Patra <[email protected]> Reviewed-by: Palmer Dabbelt <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ard Biesheuvel <[email protected]>
2020-04-14efi/libstub/file: Merge file name buffers to reduce stack usageArd Biesheuvel1-13/+14
Arnd reports that commit 9302c1bb8e47 ("efi/libstub: Rewrite file I/O routine") reworks the file I/O routines in a way that triggers the following warning: drivers/firmware/efi/libstub/file.c:240:1: warning: the frame size of 1200 bytes is larger than 1024 bytes [-Wframe-larger-than=] We can work around this issue dropping an instance of efi_char16_t[256] from the stack frame, and reusing the 'filename' field of the file info struct that we use to obtain file information from EFI (which contains the file name even though we already know it since we used it to open the file in the first place) Reported-by: Arnd Bergmann <[email protected]> Signed-off-by: Ard Biesheuvel <[email protected]> Signed-off-by: Ingo Molnar <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2020-04-14efi/x86: Always relocate the kernel for EFI handover entryArvind Sankar1-4/+10
Commit d5cdf4cfeac9 ("efi/x86: Don't relocate the kernel unless necessary") tries to avoid relocating the kernel in the EFI stub as far as possible. However, when systemd-boot is used to boot a unified kernel image [1], the image is constructed by embedding the bzImage as a .linux section in a PE executable that contains a small stub loader from systemd that will call the EFI stub handover entry, together with additional sections and potentially an initrd. When this image is constructed, by for example dracut, the initrd is placed after the bzImage without ensuring that at least init_size bytes are available for the bzImage. If the kernel is not relocated by the EFI stub, this could result in the compressed kernel's startup code in head_{32,64}.S overwriting the initrd. To prevent this, unconditionally relocate the kernel if the EFI stub was entered via the handover entry point. [1] https://systemd.io/BOOT_LOADER_SPECIFICATION/#type-2-efi-unified-kernel-images Fixes: d5cdf4cfeac9 ("efi/x86: Don't relocate the kernel unless necessary") Reported-by: Sergey Shatunov <[email protected]> Signed-off-by: Arvind Sankar <[email protected]> Signed-off-by: Ard Biesheuvel <[email protected]> Signed-off-by: Ingo Molnar <[email protected]> Link: https://lore.kernel.org/r/[email protected] Link: https://lore.kernel.org/r/[email protected]
2020-04-14efi/x86: Move efi stub globals from .bss to .dataArvind Sankar2-2/+2
Commit 3ee372ccce4d ("x86/boot/compressed/64: Remove .bss/.pgtable from bzImage") removed the .bss section from the bzImage. However, while a PE loader is required to zero-initialize the .bss section before calling the PE entry point, the EFI handover protocol does not currently document any requirement that .bss be initialized by the bootloader prior to calling the handover entry. When systemd-boot is used to boot a unified kernel image [1], the image is constructed by embedding the bzImage as a .linux section in a PE executable that contains a small stub loader from systemd together with additional sections and potentially an initrd. As the .bss section within the bzImage is no longer explicitly present as part of the file, it is not initialized before calling the EFI handover entry. Furthermore, as the size of the embedded .linux section is only the size of the bzImage file itself, the .bss section's memory may not even have been allocated. In particular, this can result in efi_disable_pci_dma being true even when it was not specified via the command line or configuration option, which in turn causes crashes while booting on some systems. To avoid issues, place all EFI stub global variables into the .data section instead of .bss. As of this writing, only boolean flags for a few command line arguments and the sys_table pointer were in .bss and will now move into the .data section. [1] https://systemd.io/BOOT_LOADER_SPECIFICATION/#type-2-efi-unified-kernel-images Fixes: 3ee372ccce4d ("x86/boot/compressed/64: Remove .bss/.pgtable from bzImage") Reported-by: Sergey Shatunov <[email protected]> Signed-off-by: Arvind Sankar <[email protected]> Signed-off-by: Ard Biesheuvel <[email protected]> Signed-off-by: Ingo Molnar <[email protected]> Link: https://lore.kernel.org/r/[email protected] Link: https://lore.kernel.org/r/[email protected]
2020-04-14efi/libstub/x86: Remove redundant assignment to pointer hdrColin Ian King1-2/+0
The pointer hdr is being assigned a value that is never read and it is being updated later with a new value. The assignment is redundant and can be removed. Addresses-Coverity: ("Unused value") Signed-off-by: Colin Ian King <[email protected]> Signed-off-by: Ard Biesheuvel <[email protected]> Signed-off-by: Ingo Molnar <[email protected]> Link: https://lore.kernel.org/r/[email protected] Link: https://lore.kernel.org/r/[email protected]
2020-04-13Merge tag 'v5.7-rc1' into locking/kcsan, to resolve conflicts and refreshIngo Molnar15-943/+2461
Resolve these conflicts: arch/x86/Kconfig arch/x86/kernel/Makefile Do a minor "evil merge" to move the KCSAN entry up a bit by a few lines in the Kconfig to reduce the probability of future conflicts. Signed-off-by: Ingo Molnar <[email protected]>
2020-04-09Merge tag 'arm64-fixes' of ↵Linus Torvalds1-5/+3
git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux Pull arm64 fixes from Catalin Marinas: - Ensure that the compiler and linker versions are aligned so that ld doesn't complain about not understanding a .note.gnu.property section (emitted when pointer authentication is enabled). - Force -mbranch-protection=none when the feature is not enabled, in case a compiler may choose a different default value. - Remove CONFIG_DEBUG_ALIGN_RODATA. It was never in defconfig and rarely enabled. - Fix checking 16-bit Thumb-2 instructions checking mask in the emulation of the SETEND instruction (it could match the bottom half of a 32-bit Thumb-2 instruction). * tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux: arm64: armv8_deprecated: Fix undef_hook mask for thumb setend arm64: remove CONFIG_DEBUG_ALIGN_RODATA feature arm64: Always force a branch protection mode when the compiler has one arm64: Kconfig: ptrauth: Add binutils version check to fix mismatch init/kconfig: Add LD_VERSION Kconfig
2020-04-01arm64: remove CONFIG_DEBUG_ALIGN_RODATA featureArd Biesheuvel1-5/+3
When CONFIG_DEBUG_ALIGN_RODATA is enabled, kernel segments mapped with different permissions (r-x for .text, r-- for .rodata, rw- for .data, etc) are rounded up to 2 MiB so they can be mapped more efficiently. In particular, it permits the segments to be mapped using level 2 block entries when using 4k pages, which is expected to result in less TLB pressure. However, the mappings for the bulk of the kernel will use level 2 entries anyway, and the misaligned fringes are organized such that they can take advantage of the contiguous bit, and use far fewer level 3 entries than would be needed otherwise. This makes the value of this feature dubious at best, and since it is not enabled in defconfig or in the distro configs, it does not appear to be in wide use either. So let's just remove it. Signed-off-by: Ard Biesheuvel <[email protected]> Acked-by: Mark Rutland <[email protected]> Acked-by: Will Deacon <[email protected]> Acked-by: Laura Abbott <[email protected]> Signed-off-by: Catalin Marinas <[email protected]>
2020-03-31Merge branch 'x86-boot-for-linus' of ↵Linus Torvalds1-1/+2
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull x86 boot updates from Ingo Molnar: "Misc cleanups and small enhancements all around the map" * 'x86-boot-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86/boot/compressed: Fix debug_puthex() parameter type x86/setup: Fix static memory detection x86/vmlinux: Drop unneeded linker script discard of .eh_frame x86/*/Makefile: Use -fno-asynchronous-unwind-tables to suppress .eh_frame sections x86/boot/compressed: Remove .eh_frame section from bzImage x86/boot/compressed/64: Remove .bss/.pgtable from bzImage x86/boot/compressed/64: Use 32-bit (zero-extended) MOV for z_output_len x86/boot/compressed/64: Use LEA to initialize boot stack pointer
2020-03-29efi/libstub/arm: Fix spurious message that an initrd was loadedArd Biesheuvel1-1/+1
Commit: ec93fc371f014a6f ("efi/libstub: Add support for loading the initrd from a device path") added a diagnostic print to the ARM version of the EFI stub that reports whether an initrd has been loaded that was passed via the command line using initrd=. However, it failed to take into account that, for historical reasons, the file loading routines return EFI_SUCCESS when no file was found, and the only way to decide whether a file was loaded is to inspect the 'size' argument that is passed by reference. So let's inspect this returned size, to prevent the print from being emitted even if no initrd was loaded at all. Signed-off-by: Ard Biesheuvel <[email protected]> Signed-off-by: Ingo Molnar <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: [email protected] Cc: [email protected]
2020-03-29efi/libstub/arm64: Avoid image_base value from efi_loaded_imageArd Biesheuvel1-1/+6
Commit: 9f9223778ef3 ("efi/libstub/arm: Make efi_entry() an ordinary PE/COFF entrypoint") did some code refactoring to get rid of the EFI entry point assembler code, and in the process, it got rid of the assignment of image_addr to the value of _text. Instead, it switched to using the image_base field of the efi_loaded_image struct provided by UEFI, which should contain the same value. However, Michael reports that this is not the case: older GRUB builds corrupt this value in some way, and since we can easily switch back to referring to _text to discover this value, let's simply do that. While at it, fix another issue in commit 9f9223778ef3, which may result in the unassigned image_addr to be misidentified as the preferred load offset of the kernel, which is unlikely but will cause a boot crash if it does occur. Finally, let's add a warning if the _text vs. image_base discrepancy is detected, so we can tell more easily how widespread this issue actually is. Reported-by: Michael Kelley <[email protected]> Tested-by: Michael Kelley <[email protected]> Signed-off-by: Ard Biesheuvel <[email protected]> Signed-off-by: Ingo Molnar <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: [email protected] Cc: [email protected]
2020-03-21Merge branch 'x86/kdump' into locking/kcsan, to resolve conflictsIngo Molnar12-525/+493
Conflicts: arch/x86/purgatory/Makefile Signed-off-by: Ingo Molnar <[email protected]>
2020-03-08efi/x86: Fix cast of image argumentArvind Sankar1-1/+1
handle_protocol() expects void **, not void *. Signed-off-by: Arvind Sankar <[email protected]> Signed-off-by: Ard Biesheuvel <[email protected]> Signed-off-by: Ingo Molnar <[email protected]> Link: https://lore.kernel.org/r/[email protected] Link: https://lore.kernel.org/r/[email protected]
Powered by cgit, Gruvboxed by Blaster4385.