EFI fixes for -next

The final build stage of the x86 kernel captures some symbol addresses from the decompressor binary and copies them into zoffset.h. It uses sed with a regular expression that matches the address, symbol type and symbol name, and mangles the captured addresses and the names of symbols of interest into #define directives that are added to zoffset.h

The symbol type is indicated by a single letter, which we match
strictly: only letters in the set 'ABCDGRSTVW' are matched, even though the actual symbol type is relevant and therefore ignored.

Commit bc7c9d620 ("efi/libstub/x86: Force 'hidden' visibility for extern declarations") made a change to the way external symbol references are classified, resulting in 'startup_32' now being emitted as a hidden symbol. This prevents the use of GOT entries to refer to this symbol via its absolute address, which recent toolchains (including Clang based ones) already avoid by default, making this change a no-op in the majority of cases.

However, as it turns out, the LLVM linker classifies such hidden symbols as symbols with static linkage in fully linked ELF binaries, causing tools such as NM to output a lowercase 't' rather than an upper case 'T' for the type of such symbols. Since our sed expression only matches upper case letters for the symbol type, the line describing startup_32 is disregarded, resulting in a build error like the following

arch/x86/boot/header.S:568:18: error: symbol 'ZO_startup_32' can not be
undefined in a subtraction expression
init_size: .long (0x00000000008fd000 - ZO_startup_32 +
(((0x0000000001f6361c + ((0x0000000001f6361c >> 8) + 65536)
- 0x00000000008c32e5) + 4095) & ~4095)) # kernel initialization size

Given that we are only interested in the value of the symbol, let's match any character in the set 'a-zA-Z' instead.

Tested-by Nathan Chancellor <[email protected]>

Cc Nick Desaulniers <[email protected]>

Signed-off-by Ard Biesheuvel <[email protected]>

---
 arch/x86/boot/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

arch/x86/boot/Makefile +1 -2

index 95410d6ee2ff..748b6d28a91d 100644
@@ -88,7 +88,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\|kernel_info\|_end\|_ehead\|_text\|z_.*\)$$/\#define ZO_\2 0x\1/p'
+sed-zoffset := -e 's/^\([0-9a-fA-F]*\) [a-zA-Z] \(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) > $@
--

2.17.1

Quoted 14 lines · Ard Biesheuvel

A couple of fixes for more unusual configurations that weren't caught in my testing before. One for KASAN, one for the LLVM linker and one for the old EFI memory map when running on mixed mode systems.

These apply onto the Git pull request [0[ that I sent out at the beginning of the week.

[0] https://lore.kernel.org/linux-efi/[email protected]/

Ard Biesheuvel (3):
efi/x86: avoid KASAN false positives when accessing the 1:1 mapping x86/boot/compressed: relax sed symbol type regex for LLVM ld.lld efi/x86: disallow efi=old_map in mixed mode

Quoted 4 lines

 arch/x86/boot/Makefile         |  2 +-
 arch/x86/platform/efi/efi_64.c | 11 ++++++-----
 arch/x86/platform/uv/bios_uv.c |  2 +-
 3 files changed, 8 insertions(+), 7 deletions(-)

Just a minor bugreport, in some (weird) config combinations we now get this build failure:

ld: arch/x86/platform/efi/efi_64.o: in function `efi_set_virtual_address_map':
efi_64.c:(.init.text+0x1419): undefined reference to `__efi64_thunk'
ld: efi_64.c:(.init.text+0x1530): undefined reference to `efi_uv1_memmap_phys_prolog'
ld: efi_64.c:(.init.text+0x1706): undefined reference to `efi_uv1_memmap_phys_epilog'

Config attached.

I believe the trigger condition is:

!CONFIG_X86_UV
CONFIG_EFI=y

Quoted 31 lines · Ingo Molnar

Quoted 14 lines · Ard Biesheuvel

A couple of fixes for more unusual configurations that weren't caught in my testing before. One for KASAN, one for the LLVM linker and one for the old EFI memory map when running on mixed mode systems.

These apply onto the Git pull request [0[ that I sent out at the beginning of the week.

[0] https://lore.kernel.org/linux-efi/[email protected]/

Ard Biesheuvel (3):
efi/x86: avoid KASAN false positives when accessing the 1:1 mapping x86/boot/compressed: relax sed symbol type regex for LLVM ld.lld efi/x86: disallow efi=old_map in mixed mode

Quoted 4 lines

 arch/x86/boot/Makefile         |  2 +-
 arch/x86/platform/efi/efi_64.c | 11 ++++++-----
 arch/x86/platform/uv/bios_uv.c |  2 +-
 3 files changed, 8 insertions(+), 7 deletions(-)

Just a minor bugreport, in some (weird) config combinations we now get this build failure:

ld: arch/x86/platform/efi/efi_64.o: in function `efi_set_virtual_address_map':
efi_64.c:(.init.text+0x1419): undefined reference to `__efi64_thunk'
ld: efi_64.c:(.init.text+0x1530): undefined reference to `efi_uv1_memmap_phys_prolog'
ld: efi_64.c:(.init.text+0x1706): undefined reference to `efi_uv1_memmap_phys_epilog'

Quoted 7 lines

Config attached.

I believe the trigger condition is:

!CONFIG_X86_UV
CONFIG_EFI=y

Strange.

Those references to missing symbols are guarded by efi_is_mixed() and efi_have_uv1_memmap(), both of which are static inline bool() functions wrapping IS_ENABLED() checks against CONFIG_EFI_MIXED and CONFIG_X86_UV, respectively. IOW, it is unexpected that the compiler doesn't const-propagate those expressions and optimize away the references entirely.