kernel/linux.git/arch/x86/boot/setup.ld, branch v6.12.80

x86/efistub: Use 1:1 file:memory mapping for PE/COFF .compat section

2024-02-05T10:24:51+00:00

The .compat section is a dummy PE section that contains the address of the 32-bit entrypoint of the 64-bit kernel image if it is bootable from 32-bit firmware (i.e., CONFIG_EFI_MIXED=y) This section is only 8 bytes in size and is only referenced from the loader, and so it is placed at the end of the memory view of the image, to avoid the need for padding it to 4k, which is required for sections appearing in the middle of the image. Unfortunately, this violates the PE/COFF spec, and even if most EFI loaders will work correctly (including the Tianocore reference implementation), PE loaders do exist that reject such images, on the basis that both the file and memory views of the file contents should be described by the section headers in a monotonically increasing manner without leaving any gaps. So reorganize the sections to avoid this issue. This results in a slight padding overhead (< 4k) which can be avoided if desired by disabling CONFIG_EFI_MIXED (which is only needed in rare cases these days) Fixes: 3e3eabe26dc8 ("x86/boot: Increase section and file alignment to 4k/512") Reported-by: Mike Beaton Link: https://lkml.kernel.org/r/CAHzAAWQ6srV6LVNdmfbJhOwhBw5ZzxxZZ07aHt9oKkfYAdvuQQ%40mail.gmail.com Signed-off-by: Ard Biesheuvel

x86/boot: Increase section and file alignment to 4k/512

2023-09-17T17:48:44+00:00

Align x86 with other EFI architectures, and increase the section alignment to the EFI page size (4k), so that firmware is able to honour the section permission attributes and map code read-only and data non-executable. There are a number of requirements that have to be taken into account: - the sign tools get cranky when there are gaps between sections in the file view of the image - the virtual offset of each section must be aligned to the image's section alignment - the file offset *and size* of each section must be aligned to the image's file alignment - the image size must be aligned to the section alignment - each section's virtual offset must be greater than or equal to the size of the headers. In order to meet all these requirements, while avoiding the need for lots of padding to accommodate the .compat section, the latter is placed at an arbitrary offset towards the end of the image, but aligned to the minimum file alignment (512 bytes). The space before the .text section is therefore distributed between the PE header, the .setup section and the .compat section, leaving no gaps in the file coverage, making the signing tools happy. Signed-off-by: Ard Biesheuvel Signed-off-by: Ingo Molnar Link: https://lore.kernel.org/r/20230915171623.655440-18-ardb@google.com

x86/boot: Drop PE/COFF .reloc section

2023-09-17T17:48:43+00:00

Ancient buggy EFI loaders may have required a .reloc section to be present at some point in time, but this has not been true for a long time so the .reloc section can just be dropped. Signed-off-by: Ard Biesheuvel Signed-off-by: Ingo Molnar Link: https://lore.kernel.org/r/20230915171623.655440-16-ardb@google.com

x86/boot: Define setup size in linker script

2023-09-17T17:48:42+00:00

The setup block contains the real mode startup code that is used when booting from a legacy BIOS, along with the boot_params/setup_data that is used by legacy x86 bootloaders to pass the command line and initial ramdisk parameters, among other things. The setup block also contains the PE/COFF header of the entire combined image, which includes the compressed kernel image, the decompressor and the EFI stub. This PE header describes the layout of the executable image in memory, and currently, the fact that the setup block precedes it makes it rather fiddly to get the right values into the right place in the final image. Let's make things a bit easier by defining the setup_size in the linker script so it can be referenced from the asm code directly, rather than having to rely on the build tool to calculate it. For the time being, add 64 bytes of fixed padding for the .reloc and .compat sections - this will be removed in a subsequent patch after the PE/COFF header has been reorganized. This change has no impact on the resulting bzImage binary when configured with CONFIG_EFI_MIXED=y. Signed-off-by: Ard Biesheuvel Signed-off-by: Ingo Molnar Link: https://lore.kernel.org/r/20230915171623.655440-13-ardb@google.com

x86/boot: Remove the 'bugger off' message

2023-09-15T09:18:41+00:00

Ancient (pre-2003) x86 kernels could boot from a floppy disk straight from the BIOS, using a small real mode boot stub at the start of the image where the BIOS would expect the boot record (or boot block) to appear. Due to its limitations (kernel size < 1 MiB, no support for IDE, USB or El Torito floppy emulation), this support was dropped, and a Linux aware bootloader is now always required to boot the kernel from a legacy BIOS. To smoothen this transition, the boot stub was not removed entirely, but replaced with one that just prints an error message telling the user to install a bootloader. As it is unlikely that anyone doing direct floppy boot with such an ancient kernel is going to upgrade to v6.5+ and expect that this boot method still works, printing this message is kind of pointless, and so it should be possible to remove the logic that emits it. Let's free up this space so it can be used to expand the PE header in a subsequent patch. Signed-off-by: Ard Biesheuvel Signed-off-by: Ingo Molnar Acked-by: H. Peter Anvin (Intel) Link: https://lore.kernel.org/r/20230912090051.4014114-21-ardb@google.com

x86/boot: Add .text.* to setup.ld

2020-08-14T10:52:35+00:00

GCC puts the main function into .text.startup when compiled with -Os (or -O2). This results in arch/x86/boot/main.c having a .text.startup section which is currently not included explicitly in the linker script setup.ld in the same directory. The BFD linker places this orphan section immediately after .text, so this still works. However, LLD git, since [1], is choosing to place it immediately after the .bstext section instead (this is the first code section). This plays havoc with the section layout that setup.elf requires to create the setup header, for eg on 64-bit: LD arch/x86/boot/setup.elf ld.lld: error: section .text.startup file range overlaps with .header >>> .text.startup range is [0x200040, 0x2001FE] >>> .header range is [0x2001EF, 0x20026B] ld.lld: error: section .header file range overlaps with .bsdata >>> .header range is [0x2001EF, 0x20026B] >>> .bsdata range is [0x2001FF, 0x200398] ld.lld: error: section .bsdata file range overlaps with .entrytext >>> .bsdata range is [0x2001FF, 0x200398] >>> .entrytext range is [0x20026C, 0x2002D3] ld.lld: error: section .text.startup virtual address range overlaps with .header >>> .text.startup range is [0x40, 0x1FE] >>> .header range is [0x1EF, 0x26B] ld.lld: error: section .header virtual address range overlaps with .bsdata >>> .header range is [0x1EF, 0x26B] >>> .bsdata range is [0x1FF, 0x398] ld.lld: error: section .bsdata virtual address range overlaps with .entrytext >>> .bsdata range is [0x1FF, 0x398] >>> .entrytext range is [0x26C, 0x2D3] ld.lld: error: section .text.startup load address range overlaps with .header >>> .text.startup range is [0x40, 0x1FE] >>> .header range is [0x1EF, 0x26B] ld.lld: error: section .header load address range overlaps with .bsdata >>> .header range is [0x1EF, 0x26B] >>> .bsdata range is [0x1FF, 0x398] ld.lld: error: section .bsdata load address range overlaps with .entrytext >>> .bsdata range is [0x1FF, 0x398] >>> .entrytext range is [0x26C, 0x2D3] Add .text.* to the .text output section to fix this, and also prevent any future surprises if the compiler decides to create other such sections. [1] https://reviews.llvm.org/D75225 Signed-off-by: Arvind Sankar Signed-off-by: Kees Cook Signed-off-by: Ingo Molnar Tested-by: Nick Desaulniers Tested-by: Sedat Dilek Reviewed-by: Kees Cook Reviewed-by: Ard Biesheuvel Reviewed-by: Fangrui Song Link: https://lore.kernel.org/r/20200731230820.1742553-5-keescook@chromium.org

x86/vmlinux: Drop unneeded linker script discard of .eh_frame

2020-02-25T13:51:29+00:00

Now that .eh_frame sections for the files in setup.elf and realmode.elf are not generated anymore, the linker scripts don't need the special output section name /DISCARD/ any more. Remove the one in the main kernel linker script as well, since there are no .eh_frame sections already, and fix up a comment referencing .eh_frame. Update the comment in asm/dwarf2.h referring to .eh_frame so it continues to make sense, as well as being more specific. [ bp: Touch up commit message. ] Signed-off-by: Arvind Sankar Signed-off-by: Borislav Petkov Reviewed-by: Nathan Chancellor Reviewed-by: Nick Desaulniers Reviewed-by: Kees Cook Tested-by: Nathan Chancellor Link: https://lkml.kernel.org/r/20200224232129.597160-3-nivedita@alum.mit.edu

x86/boot: Discard .eh_frame sections

2019-12-13T10:45:59+00:00

When using GCC as compiler and LLVM's lld as linker, linking setup.elf fails: LD arch/x86/boot/setup.elf ld.lld: error: init sections too big! This happens because GCC generates .eh_frame sections for most of the files in that directory, then ld.lld places the merged section before __end_init, triggering an assert in the linker script. Fix this by discarding the .eh_frame sections, as suggested by Boris. The kernel proper linker script discards them too. [ bp: Going back in history, 64-bit kernel proper has been discarding .eh_frame since 2002: commit acca80acefe20420e69561cf55be64f16c34ea97 Author: Andi Kleen Date: Tue Oct 29 23:54:35 2002 -0800 [PATCH] x86-64 updates for 2.5.44 ... - Remove the .eh_frame on linking. This saves several hundred KB in the bzImage ] Suggested-by: Borislav Petkov Signed-off-by: Ilie Halip Signed-off-by: Borislav Petkov Reviewed-by: Nick Desaulniers Cc: clang-built-linux@googlegroups.com Cc: "H. Peter Anvin" Cc: Ingo Molnar Cc: Thomas Gleixner Cc: x86-ml Link: https://lore.kernel.org/lkml/20191118175223.GM6363@zn.tnic/ Link: https://github.com/ClangBuiltLinux/linux/issues/760 Link: https://lkml.kernel.org/r/20191126144545.19354-1-ilie.halip@gmail.com

x86/build: Use the single-argument OUTPUT_FORMAT() linker script command

2019-01-16T11:21:53+00:00

The various x86 linker scripts use the three-argument linker script command variant OUTPUT_FORMAT(DEFAULT, BIG, LITTLE) which specifies three object file formats when the -EL and -EB linker command line options are used. When -EB is specified, OUTPUT_FORMAT issues the BIG object file format, when -EL, LITTLE, respectively, and when neither is specified, DEFAULT. However, those -E[LB] options are not used by arch/x86/ so switch to the simple OUTPUT_FORMAT(BFDNAME) macro variant. No functional changes. Signed-off-by: Borislav Petkov Cc: "H. Peter Anvin" Cc: x86@kernel.org Link: https://lkml.kernel.org/r/20190109181531.27513-1-bp@alien8.de

x86, boot: Define the 2.12 bzImage boot protocol

2013-01-27T23:56:37+00:00

Define the 2.12 bzImage boot protocol: add xloadflags and additional fields to allow the command line, initramfs and struct boot_params to live above the 4 GiB mark. The xloadflags now communicates if this is a 64-bit kernel with the legacy 64-bit entry point and which of the EFI handover entry points are supported. Avoid adding new read flags to loadflags because of claimed bootloaders testing the whole byte for == 1 to determine bzImageness at least until the issue can be researched further. This is based on patches by Yinghai Lu and David Woodhouse. Originally-by: Yinghai Lu Originally-by: David Woodhouse Acked-by: Yinghai Lu Acked-by: David Woodhouse Acked-by: Matt Fleming Signed-off-by: H. Peter Anvin Link: http://lkml.kernel.org/r/1359058816-7615-26-git-send-email-yinghai@kernel.org Cc: Rob Landley Cc: Gokul Caushik Cc: Josh Triplett Cc: Joe Millenbach