From 9e2276fa6eb39817dcc4cda415f0199fb7016b37 Mon Sep 17 00:00:00 2001 From: Bruce Ashfield Date: Thu, 26 Sep 2019 10:32:26 +0100 Subject: arch/x86/boot: Use prefix map to avoid embedded paths It was observed that the kernel embeds the absolute build path in the x86 boot image when the __FILE__ macro is expanded. > From https://bugzilla.yoctoproject.org/show_bug.cgi?id=13458: If you turn on the buildpaths QA test, or try a reproducible build, you discover that the kernel image contains build paths. $ strings bzImage-5.0.19-yocto-standard |grep tmp/ out of pgt_buf in /data/poky-tmp/reproducible/tmp/work-shared/qemux86-64/kernel-source/arch/x86/boot/compressed/kaslr_64.c!? But what's this in the top-level Makefile: $ git grep prefix-map Makefile:KBUILD_CFLAGS += $(call cc-option,-fmacro-prefix-map=$(srctree)/=) So the __FILE__ shouldn't be using the full path. However arch/x86/boot/compressed/Makefile has this: KBUILD_CFLAGS := -m$(BITS) -O2 So that clears KBUILD_FLAGS, removing the -fmacro-prefix-map option. Use -fmacro-prefix-map to have relative paths in the boot image too. [ bp: Massage commit message and put the KBUILD_CFLAGS addition in ..boot/Makefile after the KBUILD_AFLAGS assignment because gas doesn't support -fmacro-prefix-map. ] Signed-off-by: Bruce Ashfield Signed-off-by: Ross Burton Signed-off-by: Borislav Petkov Cc: "H. Peter Anvin" Cc: George Rimar Cc: Ingo Molnar Cc: Masahiro Yamada Cc: Nathan Chancellor Cc: Thomas Gleixner Cc: x86-ml Link: https://lkml.kernel.org/r/20190926093226.8568-1-ross.burton@intel.com Link: https://bugzilla.kernel.org/show_bug.cgi?id=204333 --- arch/x86/boot/Makefile | 1 + 1 file changed, 1 insertion(+) (limited to 'arch/x86/boot/Makefile') diff --git a/arch/x86/boot/Makefile b/arch/x86/boot/Makefile index e2839b5c246c..3e9f5544820a 100644 --- a/arch/x86/boot/Makefile +++ b/arch/x86/boot/Makefile @@ -67,6 +67,7 @@ clean-files += cpustr.h KBUILD_CFLAGS := $(REALMODE_CFLAGS) -D_SETUP KBUILD_AFLAGS := $(KBUILD_CFLAGS) -D__ASSEMBLY__ +KBUILD_CFLAGS += $(call cc-option,-fmacro-prefix-map=$(srctree)/=) GCOV_PROFILE := n UBSAN_SANITIZE := n -- cgit v1.2.3 From 2c33c27fd6033ced942c9a591b8ac15c07c57d70 Mon Sep 17 00:00:00 2001 From: Daniel Kiper Date: Tue, 12 Nov 2019 14:46:38 +0100 Subject: x86/boot: Introduce kernel_info The relationships between the headers are analogous to the various data sections: setup_header = .data boot_params/setup_data = .bss What is missing from the above list? That's right: kernel_info = .rodata We have been (ab)using .data for things that could go into .rodata or .bss for a long time, for lack of alternatives and -- especially early on -- inertia. Also, the BIOS stub is responsible for creating boot_params, so it isn't available to a BIOS-based loader (setup_data is, though). setup_header is permanently limited to 144 bytes due to the reach of the 2-byte jump field, which doubles as a length field for the structure, combined with the size of the "hole" in struct boot_params that a protected-mode loader or the BIOS stub has to copy it into. It is currently 119 bytes long, which leaves us with 25 very precious bytes. This isn't something that can be fixed without revising the boot protocol entirely, breaking backwards compatibility. boot_params proper is limited to 4096 bytes, but can be arbitrarily extended by adding setup_data entries. It cannot be used to communicate properties of the kernel image, because it is .bss and has no image-provided content. kernel_info solves this by providing an extensible place for information about the kernel image. It is readonly, because the kernel cannot rely on a bootloader copying its contents anywhere, but that is OK; if it becomes necessary it can still contain data items that an enabled bootloader would be expected to copy into a setup_data chunk. Do not bump setup_header version in arch/x86/boot/header.S because it will be followed by additional changes coming into the Linux/x86 boot protocol. Suggested-by: H. Peter Anvin (Intel) Signed-off-by: Daniel Kiper Signed-off-by: Borislav Petkov Reviewed-by: Konrad Rzeszutek Wilk Reviewed-by: Ross Philipson Reviewed-by: H. Peter Anvin (Intel) Cc: Andy Lutomirski Cc: ard.biesheuvel@linaro.org Cc: Boris Ostrovsky Cc: dave.hansen@linux.intel.com Cc: eric.snowberg@oracle.com Cc: Ingo Molnar Cc: Jonathan Corbet Cc: Juergen Gross Cc: kanth.ghatraju@oracle.com Cc: linux-doc@vger.kernel.org Cc: linux-efi Cc: Peter Zijlstra Cc: rdunlap@infradead.org Cc: ross.philipson@oracle.com Cc: Thomas Gleixner Cc: x86-ml Cc: xen-devel@lists.xenproject.org Link: https://lkml.kernel.org/r/20191112134640.16035-2-daniel.kiper@oracle.com --- arch/x86/boot/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'arch/x86/boot/Makefile') diff --git a/arch/x86/boot/Makefile b/arch/x86/boot/Makefile index e2839b5c246c..c30a9b642a86 100644 --- a/arch/x86/boot/Makefile +++ b/arch/x86/boot/Makefile @@ -87,7 +87,7 @@ $(obj)/vmlinux.bin: $(obj)/compressed/vmlinux FORCE SETUP_OBJS = $(addprefix $(obj)/,$(setup-y)) -sed-zoffset := -e 's/^\([0-9a-fA-F]*\) [ABCDGRSTVW] \(startup_32\|startup_64\|efi32_stub_entry\|efi64_stub_entry\|efi_pe_entry\|input_data\|_end\|_ehead\|_text\|z_.*\)$$/\#define ZO_\2 0x\1/p' +sed-zoffset := -e 's/^\([0-9a-fA-F]*\) [ABCDGRSTVW] \(startup_32\|startup_64\|efi32_stub_entry\|efi64_stub_entry\|efi_pe_entry\|input_data\|kernel_info\|_end\|_ehead\|_text\|z_.*\)$$/\#define ZO_\2 0x\1/p' quiet_cmd_zoffset = ZOFFSET $@ cmd_zoffset = $(NM) $< | sed -n $(sed-zoffset) > $@ -- cgit v1.2.3