Changes in Makefile

97282e6d - x86: drop unnecessary prefix map configuration

Sat, 22 Mar 2025 09:03:16 +0000

x86: drop unnecessary prefix map configurationThe toplevel Makefile already provides -fmacro-prefix-map as part ofKBUILD_CPPFLAGS. In contrast to the KBUILD_CFLAGS and KBUILD_AFLAGSvariables, KBUILD_CPPFLAGS is not redefined in the architecture specificMakefiles. Therefore the toplevel KBUILD_CPPFLAGS do apply just fine, toboth C and ASM sources.The custom configuration was necessary when it was added incommit 9e2276fa6eb3 ("arch/x86/boot: Use prefix map to avoid embeddedpaths") but has since become unnecessary in commit a716bd743210("kbuild: use -fmacro-prefix-map for .S sources").Drop the now unnecessary custom prefix map configuration.Signed-off-by: Thomas Weißschuh Signed-off-by: Masahiro Yamada List of files: /linux-6.15/arch/x86/boot/compressed/Makefile

e6a03a66 - x86: Get rid of Makefile.postlink

Tue, 11 Mar 2025 11:06:21 +0000

x86: Get rid of Makefile.postlinkInstead of generating the vmlinux.relocs file (needed by thedecompressor build to construct the KASLR relocation tables) as avmlinux postlink step, which is dubious because it depends on data thatis stripped from vmlinux before the build completes, generate it fromvmlinux.unstripped, which has been introduced specifically for thispurpose.This ensures that each artifact is rebuilt as needed, rather than as aside effect of another build rule.This effectively reverts commit 9d9173e9ceb6 ("x86/build: Avoid relocation information in final vmlinux")Signed-off-by: Ard Biesheuvel Signed-off-by: Masahiro Yamada List of files: /linux-6.15/arch/x86/boot/compressed/Makefile

e27dffba - x86/boot: Move the LA57 trampoline to separate source file

Thu, 13 Mar 2025 12:03:25 +0000

x86/boot: Move the LA57 trampoline to separate source fileTo permit the EFI stub to call this code even when building the kernelwithout the legacy decompressor, move the trampoline out of the latter'sstartup code.This is part of an ongoing WIP effort on my part to make the existing,generic EFI zboot format work on x86 as well.No functional change intended.Signed-off-by: Ard Biesheuvel Signed-off-by: Ingo Molnar Link: https://lore.kernel.org/r/20250313120324.1095968-2-ardb+git@google.com List of files: /linux-6.15/arch/x86/boot/compressed/Makefile

fb84cefd - x86/efi/mixed: Move mixed mode startup code into libstub

Tue, 07 Jan 2025 17:16:59 +0000

x86/efi/mixed: Move mixed mode startup code into libstubThe EFI mixed mode code has been decoupled from the legacy decompressor,in order to be able to reuse it with generic EFI zboot images for x86.Move the source file into the libstub source directory to facilitatethis.Acked-by: Ingo Molnar Signed-off-by: Ard Biesheuvel List of files: /linux-6.15/arch/x86/boot/compressed/Makefile

ee2ab467 - x86/boot: Use '-std=gnu11' to fix build with GCC 15

Wed, 22 Jan 2025 01:11:33 +0000

x86/boot: Use '-std=gnu11' to fix build with GCC 15GCC 15 changed the default C standard version to C23, which should nothave impacted the kernel because it requests the gnu11 standard via'-std=' in the main Makefile. However, the x86 compressed boot Makefileuses its own set of KBUILD_CFLAGS without a '-std=' value (i.e., usingthe default), resulting in errors from the kernel's definitions of bool,true, and false in stddef.h, which are reserved keywords under C23. ./include/linux/stddef.h:11:9: error: expected identifier before ‘false’ 11 | false = 0, ./include/linux/types.h:35:33: error: two or more data types in declaration specifiers 35 | typedef _Bool bool;Set '-std=gnu11' in the x86 compressed boot Makefile to resolve theerror and consistently use the same C standard version for the entirekernel.Closes: https://lore.kernel.org/4OAhbllK7x4QJGpZjkYjtBYNLd_2whHx9oFiuZcGwtVR4hIzvduultkgfAIRZI3vQpZylu7Gl929HaYFRGeMEalWCpeMzCIIhLxxRhq4U-Y=@protonmail.com/Closes: https://lore.kernel.org/Z4467umXR2PZ0M1H@tucnak/Reported-by: Kostadin Shishmanov Reported-by: Jakub Jelinek Signed-off-by: Nathan Chancellor Signed-off-by: Dave Hansen Reviewed-by: Ard Biesheuvel Cc:stable@vger.kernel.orgLink: https://lore.kernel.org/all/20250121-x86-use-std-consistently-gcc-15-v1-1-8ab0acf645cb%40kernel.org List of files: /linux-6.15/arch/x86/boot/compressed/Makefile

b2747f10 - x86/boot: Don't add the EFI stub to targets, again

Wed, 12 Jun 2024 19:44:44 +0000

x86/boot: Don't add the EFI stub to targets, againThis is a re-commit of da05b143a308 ("x86/boot: Don't add the EFI stub to targets")after the tagged patch incorrectly reverted it.vmlinux-objs-y is added to targets, with an assumption that they are allrelative to $(obj); adding a $(objtree)/drivers/... path causes thebuild to incorrectly create a uselessarch/x86/boot/compressed/drivers/... directory tree.Fix this just by using a different make variable for the EFI stub.Fixes: cb8bda8ad443 ("x86/boot/compressed: Rename efi_thunk_64.S to efi-mixed.S")Signed-off-by: Ben Segall Signed-off-by: Borislav Petkov (AMD) Reviewed-by: Ard Biesheuvel Cc: stable@vger.kernel.org # v6.1+Link: https://lore.kernel.org/r/xm267ceukksz.fsf@bsegall.svl.corp.google.com List of files: /linux-6.15/arch/x86/boot/compressed/Makefile

7f7f6f7a - Makefile: remove redundant tool coverage variables

Mon, 06 May 2024 13:35:43 +0000

Makefile: remove redundant tool coverage variablesNow Kbuild provides reasonable defaults for objtool, sanitizers, andprofilers.Remove redundant variables.Note:This commit changes the coverage for some objects: - include arch/mips/vdso/vdso-image.o into UBSAN, GCOV, KCOV - include arch/sparc/vdso/vdso-image-*.o into UBSAN - include arch/sparc/vdso/vma.o into UBSAN - include arch/x86/entry/vdso/extable.o into KASAN, KCSAN, UBSAN, GCOV, KCOV - include arch/x86/entry/vdso/vdso-image-*.o into KASAN, KCSAN, UBSAN, GCOV, KCOV - include arch/x86/entry/vdso/vdso32-setup.o into KASAN, KCSAN, UBSAN, GCOV, KCOV - include arch/x86/entry/vdso/vma.o into GCOV, KCOV - include arch/x86/um/vdso/vma.o into KASAN, GCOV, KCOVI believe these are positive effects because all of them are kernelspace objects.Signed-off-by: Masahiro Yamada Reviewed-by: Kees Cook Tested-by: Roberto Sassu List of files: /linux-6.15/arch/x86/boot/compressed/Makefile

9c554610 - x86/efistub: Remap kernel text read-only before dropping NX attribute

Thu, 25 Jan 2024 13:32:07 +0000

x86/efistub: Remap kernel text read-only before dropping NX attributeCurrently, the EFI stub invokes the EFI memory attributes protocol tostrip any NX restrictions from the entire loaded kernel, resulting inall code and data being mapped read-write-execute.The point of the EFI memory attributes protocol is to remove the needfor all memory allocations to be mapped with both write and executepermissions by default, and make it the OS loader's responsibility totransition data mappings to code mappings where appropriate.Even though the UEFI specification does not appear to leave room fordenying memory attribute changes based on security policy, let's becautious and avoid relying on the ability to create read-write-executemappings. This is trivially achievable, given that the amount of kernelcode executing via the firmware's 1:1 mapping is rather small andlimited to the .head.text region. So let's drop the NX restrictions onlyon that subregion, but not before remapping it as read-only first.Signed-off-by: Ard Biesheuvel List of files: /linux-6.15/arch/x86/boot/compressed/Makefile

54aa699e - arch/x86: Fix typos

Wed, 03 Jan 2024 00:40:11 +0000

arch/x86: Fix typosFix typos, most reported by "codespell arch/x86". Only touches comments,no code changes.Signed-off-by: Bjorn Helgaas Signed-off-by: Ingo Molnar Reviewed-by: Randy Dunlap Link: https://lore.kernel.org/r/20240103004011.1758650-1-helgaas@kernel.org List of files: /linux-6.15/arch/x86/boot/compressed/Makefile

a1b87d54 - x86/efistub: Avoid legacy decompressor when doing EFI boot

Mon, 07 Aug 2023 16:27:20 +0000

x86/efistub: Avoid legacy decompressor when doing EFI bootThe bare metal decompressor code was never really intended to run in ahosted environment such as the EFI boot services, and does a few thingsthat are becoming problematic in the context of EFI boot now that thelogo requirements are getting tighter: EFI executables will no longer beallowed to consist of a single executable section that is mapped withread, write and execute permissions if they are intended for use in acontext where Secure Boot is enabled (and where Microsoft's set ofcertificates is used, i.e., every x86 PC built to run Windows).To avoid stepping on reserved memory before having inspected the E820tables, and to ensure the correct placement when running a kernel buildthat is non-relocatable, the bare metal decompressor moves its ownexecutable image to the end of the allocation that was reserved for it,in order to perform the decompression in place. This means the region inquestion requires both write and execute permissions, which either needto be given upfront (which EFI will no longer permit), or need to beapplied on demand using the existing page fault handling framework.However, the physical placement of the kernel is usually randomizedanyway, and even if it isn't, a dedicated decompression output buffercan be allocated anywhere in memory using EFI APIs when still running inthe boot services, given that EFI support already implies a relocatablekernel. This means that decompression in place is never necessary, noris moving the compressed image from one end to the other.Since EFI already maps all of memory 1:1, it is also unnecessary tocreate new page tables or handle page faults when decompressing thekernel. That means there is also no need to replace the specialexception handlers for SEV. Generally, there is little need to doany of the things that the decompressor does beyond- initialize SEV encryption, if needed,- perform the 4/5 level paging switch, if needed,- decompress the kernel- relocate the kernelSo do all of this from the EFI stub code, and avoid the bare metaldecompressor altogether.Signed-off-by: Ard Biesheuvel Signed-off-by: Borislav Petkov (AMD) Link: https://lore.kernel.org/r/20230807162720.545787-24-ardb@kernel.org List of files: /linux-6.15/arch/x86/boot/compressed/Makefile

9d9173e9 - x86/build: Avoid relocation information in final vmlinux

Mon, 27 Mar 2023 09:54:06 +0000

x86/build: Avoid relocation information in final vmlinuxThe Linux build process on x86 roughly consists of compiling all inputfiles, statically linking them into a vmlinux ELF file, and then takingand turning this file into an actual bzImage bootable file.vmlinux has in this process two main purposes:1) It is an intermediate build target on the way to produce the final bootable image.2) It is a file that is expected to be used by debuggers and standard ELF tooling to work with the built kernel.For the second purpose, a vmlinux file is typically collected by variouspackage build recipes, such as distribution spec files, including thekernel's own tar-pkg target.When building a kernel supporting KASLR with CONFIG_X86_NEED_RELOCS,vmlinux contains also relocation information produced by using the--emit-relocs linker option. This is utilized by subsequent build stepsto create vmlinux.relocs and produce a relocatable image. However, theinformation is not needed by debuggers and other standard ELF tooling.The issue is then that the collected vmlinux file and hence distributionpackages end up unnecessarily large because of this extra data. Thefollowing is a size comparison of vmlinux v6.0 with and without therelocation information: | Configuration | With relocs | Stripped relocs | | x86_64_defconfig | 70 MB | 43 MB | | +CONFIG_DEBUG_INFO | 818 MB | 367 MB |Optimize a resulting vmlinux by adding a postlink step that splits therelocation information into vmlinux.relocs and then strips it from thevmlinux binary.Signed-off-by: Petr Pavlu Signed-off-by: Borislav Petkov (AMD) Tested-by: Nick Desaulniers Link: https://lore.kernel.org/r/20220927084632.14531-1-petr.pavlu@suse.com List of files: /linux-6.15/arch/x86/boot/compressed/Makefile

75d090fd - x86/tdx: Add unaccepted memory support

Tue, 06 Jun 2023 14:26:37 +0000

x86/tdx: Add unaccepted memory supportHookup TDX-specific code to accept memory.Accepting the memory is done with ACCEPT_PAGE module call on every pagein the range. MAP_GPA hypercall is not required as the unaccepted memoryis considered private already.Extract the part of tdx_enc_status_changed() that does memory acceptancein a new helper. Move the helper tdx-shared.c. It is going to be used byboth main kernel and decompressor. [ bp: Fix the INTEL_TDX_GUEST=y, KVM_GUEST=n build. ]Signed-off-by: Kirill A. Shutemov Signed-off-by: Borislav Petkov (AMD) Link: https://lore.kernel.org/r/20230606142637.5171-10-kirill.shutemov@linux.intel.com List of files: /linux-6.15/arch/x86/boot/compressed/Makefile

745e3ed8 - efi/libstub: Implement support for unaccepted memory

Tue, 06 Jun 2023 14:26:31 +0000

efi/libstub: Implement support for unaccepted memoryUEFI Specification version 2.9 introduces the concept of memoryacceptance: Some Virtual Machine platforms, such as Intel TDX or AMDSEV-SNP, requiring memory to be accepted before it can be used by theguest. Accepting happens via a protocol specific for the VirtualMachine platform.Accepting memory is costly and it makes VMM allocate memory for theaccepted guest physical address range. It's better to postpone memoryacceptance until memory is needed. It lowers boot time and reducesmemory overhead.The kernel needs to know what memory has been accepted. Firmwarecommunicates this information via memory map: a new memory type --EFI_UNACCEPTED_MEMORY -- indicates such memory.Range-based tracking works fine for firmware, but it gets bulky forthe kernel: e820 (or whatever the arch uses) has to be modified on everypage acceptance. It leads to table fragmentation and there's a limitednumber of entries in the e820 table.Another option is to mark such memory as usable in e820 and track if therange has been accepted in a bitmap. One bit in the bitmap represents anaturally aligned power-2-sized region of address space -- unit.For x86, unit size is 2MiB: 4k of the bitmap is enough to track 64GiB orphysical address space.In the worst-case scenario -- a huge hole in the middle of theaddress space -- It needs 256MiB to handle 4PiB of the addressspace.Any unaccepted memory that is not aligned to unit_size gets acceptedupfront.The bitmap is allocated and constructed in the EFI stub and passed downto the kernel via EFI configuration table. allocate_e820() allocates thebitmap if unaccepted memory is present, according to the size ofunaccepted region.Signed-off-by: Kirill A. Shutemov Signed-off-by: Borislav Petkov (AMD) Reviewed-by: Ard Biesheuvel Link: https://lore.kernel.org/r/20230606142637.5171-4-kirill.shutemov@linux.intel.com List of files: /linux-6.15/arch/x86/boot/compressed/Makefile

994f5f78 - x86/boot/compressed: prefer cc-option for CFLAGS additions

Thu, 12 Jan 2023 03:04:58 +0000

x86/boot/compressed: prefer cc-option for CFLAGS additionsas-option tests new options using KBUILD_CFLAGS, which causes problemswhen using as-option to update KBUILD_AFLAGS because many compileroptions are not valid assembler options.This will be fixed in a follow up patch. Before doing so, move theassembler test for -Wa,-mrelax-relocations=no from using as-option tocc-option.Link: https://lore.kernel.org/llvm/CAK7LNATcHt7GcXZ=jMszyH=+M_LC9Qr6yeAGRCBbE6xriLxtUQ@mail.gmail.com/Suggested-by: Masahiro Yamada Reviewed-by: Nathan Chancellor Tested-by: Nathan Chancellor Signed-off-by: Nick Desaulniers Signed-off-by: Nathan Chancellor Tested-by: Linux Kernel Functional Testing Tested-by: Anders Roxell Signed-off-by: Masahiro Yamada List of files: /linux-6.15/arch/x86/boot/compressed/Makefile

61de13df - x86/boot/compressed: Only build mem_encrypt.S if AMD_MEM_ENCRYPT=y

Tue, 22 Nov 2022 16:10:16 +0000

x86/boot/compressed: Only build mem_encrypt.S if AMD_MEM_ENCRYPT=yAvoid building the mem_encrypt.o object if memory encryption support isnot enabled to begin with.Signed-off-by: Ard Biesheuvel Signed-off-by: Borislav Petkov Link: https://lore.kernel.org/r/20221122161017.2426828-17-ardb@kernel.org List of files: /linux-6.15/arch/x86/boot/compressed/Makefile

cb8bda8a - x86/boot/compressed: Rename efi_thunk_64.S to efi-mixed.S

Tue, 22 Nov 2022 16:10:01 +0000

x86/boot/compressed: Rename efi_thunk_64.S to efi-mixed.SIn preparation for moving the mixed mode specific code out of head_64.S,rename the existing file to clarify that it contains more than just themixed mode thunk.While at it, clean up the Makefile rules that add it to the build.Signed-off-by: Ard Biesheuvel Signed-off-by: Borislav Petkov Link: https://lore.kernel.org/r/20221122161017.2426828-2-ardb@kernel.org List of files: /linux-6.15/arch/x86/boot/compressed/Makefile

e1789d7c - kbuild: upgrade the orphan section warning to an error if CONFIG_WERROR is set

Tue, 25 Oct 2022 07:30:23 +0000

kbuild: upgrade the orphan section warning to an error if CONFIG_WERROR is setAndrew Cooper suggested upgrading the orphan section warning to a hard linkerror. However Nathan Chancellor said outright turning the warning into anerror with no escape hatch might be too aggressive, as we have had thesewarnings triggered by new compiler generated sections, and suggested turningorphan sections into an error only if CONFIG_WERROR is set. Kees Cook echoedand emphasized that the mandate from Linus is that we should avoid breakingbuilds. It wrecks bisection, it causes problems across compiler versions, etc.Thus upgrade the orphan section warning to a hard link error only ifCONFIG_WERROR is set.Suggested-by: Andrew Cooper Suggested-by: Nathan Chancellor Signed-off-by: Xin Li Reviewed-by: Nathan Chancellor Tested-by: Nathan Chancellor Signed-off-by: Kees Cook Link: https://lore.kernel.org/r/20221025073023.16137-2-xin3.li@intel.com List of files: /linux-6.15/arch/x86/boot/compressed/Makefile

93324e68 - x86: kmsan: disable instrumentation of unsupported code

Thu, 15 Sep 2022 15:04:06 +0000

x86: kmsan: disable instrumentation of unsupported codeInstrumenting some files with KMSAN will result in kernel being unable tolink, boot or crashing at runtime for various reasons (e.g. infiniterecursion caused by instrumentation hooks calling instrumented codeagain).Completely omit KMSAN instrumentation in the following places: - arch/x86/boot and arch/x86/realmode/rm, as KMSAN doesn't work for i386; - arch/x86/entry/vdso, which isn't linked with KMSAN runtime; - three files in arch/x86/kernel - boot problems; - arch/x86/mm/cpu_entry_area.c - recursion.Link: https://lkml.kernel.org/r/20220915150417.722975-33-glider@google.comSigned-off-by: Alexander Potapenko Cc: Alexander Viro Cc: Alexei Starovoitov Cc: Andrey Konovalov Cc: Andrey Konovalov Cc: Andy Lutomirski Cc: Arnd Bergmann Cc: Borislav Petkov Cc: Christoph Hellwig Cc: Christoph Lameter Cc: David Rientjes Cc: Dmitry Vyukov Cc: Eric Biggers Cc: Eric Biggers Cc: Eric Dumazet Cc: Greg Kroah-Hartman Cc: Herbert Xu Cc: Ilya Leoshkevich Cc: Ingo Molnar Cc: Jens Axboe Cc: Joonsoo Kim Cc: Kees Cook Cc: Marco Elver Cc: Mark Rutland Cc: Matthew Wilcox Cc: Michael S. Tsirkin Cc: Pekka Enberg Cc: Peter Zijlstra Cc: Petr Mladek Cc: Stephen Rothwell Cc: Steven Rostedt Cc: Thomas Gleixner Cc: Vasily Gorbik Cc: Vegard Nossum Cc: Vlastimil Babka Signed-off-by: Andrew Morton List of files: /linux-6.15/arch/x86/boot/compressed/Makefile

ffcf9c57 - x86: link vdso and boot with -z noexecstack --no-warn-rwx-segments

Wed, 10 Aug 2022 22:24:41 +0000

x86: link vdso and boot with -z noexecstack --no-warn-rwx-segmentsUsers of GNU ld (BFD) from binutils 2.39+ will observe multipleinstances of a new warning when linking kernels in the form: ld: warning: arch/x86/boot/pmjump.o: missing .note.GNU-stack section implies executable stack ld: NOTE: This behaviour is deprecated and will be removed in a future version of the linker ld: warning: arch/x86/boot/compressed/vmlinux has a LOAD segment with RWX permissionsGenerally, we would like to avoid the stack being executable. Becausethere could be a need for the stack to be executable, assembler sourceshave to opt-in to this security feature via explicit creation of the.note.GNU-stack feature (which compilers create by default) or commandline flag --noexecstack. Or we can simply tell the linker theproduction of such sections is irrelevant and to link the stack as--noexecstack.LLVM's LLD linker defaults to -z noexecstack, so this flag isn'tstrictly necessary when linking with LLD, only BFD, but it doesn't hurtto be explicit here for all linkers IMO. --no-warn-rwx-segments iscurrently BFD specific and only available in the current latest release,so it's wrapped in an ld-option check.While the kernel makes extensive usage of ELF sections, it doesn't usepermissions from ELF segments.Link: https://lore.kernel.org/linux-block/3af4127a-f453-4cf7-f133-a181cce06f73@kernel.dk/Link: https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=ba951afb99912da01a6e8434126b8fac7aa75107Link: https://github.com/llvm/llvm-project/issues/57009Reported-and-tested-by: Jens Axboe Suggested-by: Fangrui Song Signed-off-by: Nick Desaulniers Signed-off-by: Linus Torvalds List of files: /linux-6.15/arch/x86/boot/compressed/Makefile

4c5b9aac - x86/boot: Port I/O: Add decompression-time support for TDX

Tue, 05 Apr 2022 23:29:25 +0000

x86/boot: Port I/O: Add decompression-time support for TDXPort I/O instructions trigger #VE in the TDX environment. In response tothe exception, kernel emulates these instructions using hypercalls.But during early boot, on the decompression stage, it is cumbersome todeal with #VE. It is cleaner to go to hypercalls directly, bypassing #VEhandling.Hook up TDX-specific port I/O helpers if booting in TDX environment.Signed-off-by: Kirill A. Shutemov Signed-off-by: Dave Hansen Reviewed-by: Dave Hansen Link: https://lkml.kernel.org/r/20220405232939.73860-17-kirill.shutemov@linux.intel.com List of files: /linux-6.15/arch/x86/boot/compressed/Makefile