[PATCH v4 0/3] arm64: EFI stub isolation

[PATCH v4 0/3] arm64: EFI stub isolation

[Ard Biesheuvel]

We need to ensure that the EFI stub only uses parts of the kernel proper
that are safe to use when the kernel virtual mapping is not active yet.

So move all C code dependencies to the libstub, which is built with all
instrumentation (gcov, kasan) disabled, and do a verification pass to
ensure that no absolute relocations are used.

On the arm64 side, annotate all the stub's dependencies as safe for PI
(position independent

@Matt: if you are OK with these, may we please have your ack on patches #1 and
#2 so that Catalin can pick up the series? Thanks.

Changes since v3:
- expose strcmp() which we will need for EFI stub patches that may enter
  mainline via another subsystem tree
- rebase onto arm64/for-next/core

Changes since v2:
- fold patch that removes the linux_banner from the /chosen node UEFI specific
  properties; if we are all in agreement that we can get rid of it (which I
  think we are), it makes sense to do it straight away, and not export
  linux_banner into the stub now only to remove it later
- tweaked libstub Makefile rules for easier ARM reuse
- rebase onto v4.3-rc4

Changes since v1:
- add .size and .type directives to correctly annotate the __pi_xxx aliases
  as functions of the correct size
- add '#ifndef __HAVE_ARCH_STRSTR' around strstr() definition
- added linux-efi/Matt to cc

Ard Biesheuvel (3):
  arm64/efi: remove /chosen/linux,uefi-stub-kern-ver DT property
  arm64: use ENDPIPROC() to annotate position independent assembler
    routines
  arm64/efi: isolate EFI stub from the kernel proper

 Documentation/arm/uefi.txt            |  2 -
 arch/arm64/include/asm/assembler.h    | 11 ++++
 arch/arm64/kernel/Makefile            | 12 ++++-
 arch/arm64/kernel/efi-entry.S         | 10 ++--
 arch/arm64/kernel/head.S              | 14 ++---
 arch/arm64/kernel/image.h             | 27 ++++++++++
 arch/arm64/lib/memchr.S               |  2 +-
 arch/arm64/lib/memcmp.S               |  2 +-
 arch/arm64/lib/memcpy.S               |  2 +-
 arch/arm64/lib/memmove.S              |  2 +-
 arch/arm64/lib/memset.S               |  2 +-
 arch/arm64/lib/strcmp.S               |  2 +-
 arch/arm64/lib/strlen.S               |  2 +-
 arch/arm64/lib/strncmp.S              |  2 +-
 arch/arm64/mm/cache.S                 | 10 ++--
 drivers/firmware/efi/libstub/Makefile | 39 +++++++++++---
 drivers/firmware/efi/libstub/fdt.c    |  9 ----
 drivers/firmware/efi/libstub/string.c | 57 ++++++++++++++++++++
 18 files changed, 163 insertions(+), 44 deletions(-)
 create mode 100644 drivers/firmware/efi/libstub/string.c

-- 
1.9.1

[PATCH v4 1/3] arm64/efi: remove /chosen/linux,uefi-stub-kern-ver DT property

[Ard Biesheuvel]

With the stub to kernel interface being promoted to a proper interface
so that other agents than the stub can boot the kernel proper in EFI
mode, we can remove the linux,uefi-stub-kern-ver field, considering
that its original purpose was to prevent this from happening in the
first place.

Signed-off-by: Ard Biesheuvel <ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
---
 Documentation/arm/uefi.txt         | 2 --
 drivers/firmware/efi/libstub/fdt.c | 9 ---------
 2 files changed, 11 deletions(-)

diff --git a/Documentation/arm/uefi.txt b/Documentation/arm/uefi.txt
index d60030a1b909..7f1bed8872f3 100644
--- a/Documentation/arm/uefi.txt
+++ b/Documentation/arm/uefi.txt
@@ -58,7 +58,5 @@ linux,uefi-mmap-desc-size | 32-bit | Size in bytes of each entry in the UEFI
 --------------------------------------------------------------------------------
 linux,uefi-mmap-desc-ver  | 32-bit | Version of the mmap descriptor format.
 --------------------------------------------------------------------------------
-linux,uefi-stub-kern-ver  | string | Copy of linux_banner from build.
---------------------------------------------------------------------------------
 
 For verbose debug messages, specify 'uefi_debug' on the kernel command line.
diff --git a/drivers/firmware/efi/libstub/fdt.c b/drivers/firmware/efi/libstub/fdt.c
index ef5d764e2a27..b62e2f5dcab3 100644
--- a/drivers/firmware/efi/libstub/fdt.c
+++ b/drivers/firmware/efi/libstub/fdt.c
@@ -147,15 +147,6 @@ efi_status_t update_fdt(efi_system_table_t *sys_table, void *orig_fdt,
 	if (status)
 		goto fdt_set_fail;
 
-	/*
-	 * Add kernel version banner so stub/kernel match can be
-	 * verified.
-	 */
-	status = fdt_setprop_string(fdt, node, "linux,uefi-stub-kern-ver",
-			     linux_banner);
-	if (status)
-		goto fdt_set_fail;
-
 	return EFI_SUCCESS;
 
 fdt_set_fail:
-- 
1.9.1

Re: [PATCH v4 1/3] arm64/efi: remove /chosen/linux,uefi-stub-kern-ver DT property

[Matt Fleming]

On Thu, 08 Oct, at 08:02:02PM, Ard Biesheuvel wrote:
> With the stub to kernel interface being promoted to a proper interface
> so that other agents than the stub can boot the kernel proper in EFI
> mode, we can remove the linux,uefi-stub-kern-ver field, considering
> that its original purpose was to prevent this from happening in the
> first place.
> 
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> ---
>  Documentation/arm/uefi.txt         | 2 --
>  drivers/firmware/efi/libstub/fdt.c | 9 ---------
>  2 files changed, 11 deletions(-)

Good riddance ;-)

Reviewed-by: Matt Fleming <matt.fleming-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>

-- 
Matt Fleming, Intel Open Source Technology Center

[PATCH v4 2/3] arm64: use ENDPIPROC() to annotate position independent assembler routines

[Ard Biesheuvel]

For more control over which functions are called with the MMU off or
with the UEFI 1:1 mapping active, annotate some assembler routines as
position independent. This is done by introducing ENDPIPROC(), which
replaces the ENDPROC() declaration of those routines.

Signed-off-by: Ard Biesheuvel <ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
---
 arch/arm64/include/asm/assembler.h | 11 +++++++++++
 arch/arm64/lib/memchr.S            |  2 +-
 arch/arm64/lib/memcmp.S            |  2 +-
 arch/arm64/lib/memcpy.S            |  2 +-
 arch/arm64/lib/memmove.S           |  2 +-
 arch/arm64/lib/memset.S            |  2 +-
 arch/arm64/lib/strcmp.S            |  2 +-
 arch/arm64/lib/strlen.S            |  2 +-
 arch/arm64/lib/strncmp.S           |  2 +-
 arch/arm64/mm/cache.S              | 10 +++++-----
 10 files changed, 24 insertions(+), 13 deletions(-)

diff --git a/arch/arm64/include/asm/assembler.h b/arch/arm64/include/asm/assembler.h
index b51f2cc22ca9..12eff928ef8b 100644
--- a/arch/arm64/include/asm/assembler.h
+++ b/arch/arm64/include/asm/assembler.h
@@ -193,4 +193,15 @@ lr	.req	x30		// link register
 	str	\src, [\tmp, :lo12:\sym]
 	.endm
 
+/*
+ * Annotate a function as position independent, i.e., safe to be called before
+ * the kernel virtual mapping is activated.
+ */
+#define ENDPIPROC(x)			\
+	.globl	__pi_##x;		\
+	.type 	__pi_##x, %function;	\
+	.set	__pi_##x, x;		\
+	.size	__pi_##x, . - x;	\
+	ENDPROC(x)
+
 #endif	/* __ASM_ASSEMBLER_H */
diff --git a/arch/arm64/lib/memchr.S b/arch/arm64/lib/memchr.S
index 8636b7549163..4444c1d25f4b 100644
--- a/arch/arm64/lib/memchr.S
+++ b/arch/arm64/lib/memchr.S
@@ -41,4 +41,4 @@ ENTRY(memchr)
 	ret
 2:	mov	x0, #0
 	ret
-ENDPROC(memchr)
+ENDPIPROC(memchr)
diff --git a/arch/arm64/lib/memcmp.S b/arch/arm64/lib/memcmp.S
index 6ea0776ba6de..ffbdec00327d 100644
--- a/arch/arm64/lib/memcmp.S
+++ b/arch/arm64/lib/memcmp.S
@@ -255,4 +255,4 @@ CPU_LE( rev	data2, data2 )
 .Lret0:
 	mov	result, #0
 	ret
-ENDPROC(memcmp)
+ENDPIPROC(memcmp)
diff --git a/arch/arm64/lib/memcpy.S b/arch/arm64/lib/memcpy.S
index 173a1aace9bb..36a6a62cf263 100644
--- a/arch/arm64/lib/memcpy.S
+++ b/arch/arm64/lib/memcpy.S
@@ -71,4 +71,4 @@
 ENTRY(memcpy)
 #include "copy_template.S"
 	ret
-ENDPROC(memcpy)
+ENDPIPROC(memcpy)
diff --git a/arch/arm64/lib/memmove.S b/arch/arm64/lib/memmove.S
index 57b19ea2dad4..68e2f2035e23 100644
--- a/arch/arm64/lib/memmove.S
+++ b/arch/arm64/lib/memmove.S
@@ -194,4 +194,4 @@ ENTRY(memmove)
 	tst	count, #0x3f
 	b.ne	.Ltail63
 	ret
-ENDPROC(memmove)
+ENDPIPROC(memmove)
diff --git a/arch/arm64/lib/memset.S b/arch/arm64/lib/memset.S
index 7c72dfd36b63..29f405f08792 100644
--- a/arch/arm64/lib/memset.S
+++ b/arch/arm64/lib/memset.S
@@ -213,4 +213,4 @@ ENTRY(memset)
 	ands	count, count, zva_bits_x
 	b.ne	.Ltail_maybe_long
 	ret
-ENDPROC(memset)
+ENDPIPROC(memset)
diff --git a/arch/arm64/lib/strcmp.S b/arch/arm64/lib/strcmp.S
index 42f828b06c59..471fe61760ef 100644
--- a/arch/arm64/lib/strcmp.S
+++ b/arch/arm64/lib/strcmp.S
@@ -231,4 +231,4 @@ CPU_BE(	orr	syndrome, diff, has_nul )
 	lsr	data1, data1, #56
 	sub	result, data1, data2, lsr #56
 	ret
-ENDPROC(strcmp)
+ENDPIPROC(strcmp)
diff --git a/arch/arm64/lib/strlen.S b/arch/arm64/lib/strlen.S
index 987b68b9ce44..55ccc8e24c08 100644
--- a/arch/arm64/lib/strlen.S
+++ b/arch/arm64/lib/strlen.S
@@ -123,4 +123,4 @@ CPU_LE( lsr	tmp2, tmp2, tmp1 )	/* Shift (tmp1 & 63).  */
 	csinv	data1, data1, xzr, le
 	csel	data2, data2, data2a, le
 	b	.Lrealigned
-ENDPROC(strlen)
+ENDPIPROC(strlen)
diff --git a/arch/arm64/lib/strncmp.S b/arch/arm64/lib/strncmp.S
index 0224cf5a5533..e267044761c6 100644
--- a/arch/arm64/lib/strncmp.S
+++ b/arch/arm64/lib/strncmp.S
@@ -307,4 +307,4 @@ CPU_BE( orr	syndrome, diff, has_nul )
 .Lret0:
 	mov	result, #0
 	ret
-ENDPROC(strncmp)
+ENDPIPROC(strncmp)
diff --git a/arch/arm64/mm/cache.S b/arch/arm64/mm/cache.S
index eb48d5df4a0f..cfa44a6adc0a 100644
--- a/arch/arm64/mm/cache.S
+++ b/arch/arm64/mm/cache.S
@@ -98,7 +98,7 @@ ENTRY(__flush_dcache_area)
 	b.lo	1b
 	dsb	sy
 	ret
-ENDPROC(__flush_dcache_area)
+ENDPIPROC(__flush_dcache_area)
 
 /*
  *	__inval_cache_range(start, end)
@@ -131,7 +131,7 @@ __dma_inv_range:
 	b.lo	2b
 	dsb	sy
 	ret
-ENDPROC(__inval_cache_range)
+ENDPIPROC(__inval_cache_range)
 ENDPROC(__dma_inv_range)
 
 /*
@@ -171,7 +171,7 @@ ENTRY(__dma_flush_range)
 	b.lo	1b
 	dsb	sy
 	ret
-ENDPROC(__dma_flush_range)
+ENDPIPROC(__dma_flush_range)
 
 /*
  *	__dma_map_area(start, size, dir)
@@ -184,7 +184,7 @@ ENTRY(__dma_map_area)
 	cmp	w2, #DMA_FROM_DEVICE
 	b.eq	__dma_inv_range
 	b	__dma_clean_range
-ENDPROC(__dma_map_area)
+ENDPIPROC(__dma_map_area)
 
 /*
  *	__dma_unmap_area(start, size, dir)
@@ -197,4 +197,4 @@ ENTRY(__dma_unmap_area)
 	cmp	w2, #DMA_TO_DEVICE
 	b.ne	__dma_inv_range
 	ret
-ENDPROC(__dma_unmap_area)
+ENDPIPROC(__dma_unmap_area)
-- 
1.9.1

[PATCH v4 3/3] arm64/efi: isolate EFI stub from the kernel proper

[Ard Biesheuvel]

Since arm64 does not use a builtin decompressor, the EFI stub is built
into the kernel proper. So far, this has been working fine, but actually,
since the stub is in fact a PE/COFF relocatable binary that is executed
at an unknown offset in the 1:1 mapping provided by the UEFI firmware, we
should not be seamlessly sharing code with the kernel proper, which is a
position dependent executable linked at a high virtual offset.

So instead, separate the contents of libstub and its dependencies, by
putting them into their own namespace by prefixing all of its symbols
with __efistub. This way, we have tight control over what parts of the
kernel proper are referenced by the stub.

Signed-off-by: Ard Biesheuvel <ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
---
 arch/arm64/kernel/Makefile            | 12 ++++-
 arch/arm64/kernel/efi-entry.S         | 10 ++--
 arch/arm64/kernel/head.S              | 14 ++---
 arch/arm64/kernel/image.h             | 27 ++++++++++
 drivers/firmware/efi/libstub/Makefile | 39 +++++++++++---
 drivers/firmware/efi/libstub/string.c | 57 ++++++++++++++++++++
 6 files changed, 139 insertions(+), 20 deletions(-)

diff --git a/arch/arm64/kernel/Makefile b/arch/arm64/kernel/Makefile
index 22dc9bc781be..7b17f6245f1e 100644
--- a/arch/arm64/kernel/Makefile
+++ b/arch/arm64/kernel/Makefile
@@ -20,6 +20,14 @@ arm64-obj-y		:= debug-monitors.o entry.o irq.o fpsimd.o		\
 			   cpufeature.o alternative.o cacheinfo.o		\
 			   smp.o smp_spin_table.o topology.o
 
+stub-obj				:= efi-stub.o efi-entry.o
+extra-y					:= $(stub-obj)
+stub-obj				:= $(patsubst %.o,%.stub.o,$(stub-obj))
+
+OBJCOPYFLAGS := --prefix-symbols=__efistub_
+$(obj)/%.stub.o: $(obj)/%.o FORCE
+	$(call if_changed,objcopy)
+
 arm64-obj-$(CONFIG_COMPAT)		+= sys32.o kuser32.o signal32.o 	\
 					   sys_compat.o entry32.o		\
 					   ../../arm/kernel/opcodes.o
@@ -32,7 +40,7 @@ arm64-obj-$(CONFIG_CPU_PM)		+= sleep.o suspend.o
 arm64-obj-$(CONFIG_CPU_IDLE)		+= cpuidle.o
 arm64-obj-$(CONFIG_JUMP_LABEL)		+= jump_label.o
 arm64-obj-$(CONFIG_KGDB)		+= kgdb.o
-arm64-obj-$(CONFIG_EFI)			+= efi.o efi-stub.o efi-entry.o
+arm64-obj-$(CONFIG_EFI)			+= efi.o $(stub-obj)
 arm64-obj-$(CONFIG_PCI)			+= pci.o
 arm64-obj-$(CONFIG_ARMV8_DEPRECATED)	+= armv8_deprecated.o
 arm64-obj-$(CONFIG_ACPI)		+= acpi.o
@@ -40,7 +48,7 @@ arm64-obj-$(CONFIG_ACPI)		+= acpi.o
 obj-y					+= $(arm64-obj-y) vdso/
 obj-m					+= $(arm64-obj-m)
 head-y					:= head.o
-extra-y					:= $(head-y) vmlinux.lds
+extra-y					+= $(head-y) vmlinux.lds
 
 # vDSO - this must be built first to generate the symbol offsets
 $(call objectify,$(arm64-obj-y)): $(obj)/vdso/vdso-offsets.h
diff --git a/arch/arm64/kernel/efi-entry.S b/arch/arm64/kernel/efi-entry.S
index 8ce9b0577442..a773db92908b 100644
--- a/arch/arm64/kernel/efi-entry.S
+++ b/arch/arm64/kernel/efi-entry.S
@@ -29,7 +29,7 @@
 	 * we want to be. The kernel image wants to be placed at TEXT_OFFSET
 	 * from start of RAM.
 	 */
-ENTRY(efi_stub_entry)
+ENTRY(entry)
 	/*
 	 * Create a stack frame to save FP/LR with extra space
 	 * for image_addr variable passed to efi_entry().
@@ -86,8 +86,8 @@ ENTRY(efi_stub_entry)
 	 * entries for the VA range of the current image, so no maintenance is
 	 * necessary.
 	 */
-	adr	x0, efi_stub_entry
-	adr	x1, efi_stub_entry_end
+	adr	x0, entry
+	adr	x1, entry_end
 	sub	x1, x1, x0
 	bl	__flush_dcache_area
 
@@ -120,5 +120,5 @@ efi_load_fail:
 	ldp	x29, x30, [sp], #32
 	ret
 
-efi_stub_entry_end:
-ENDPROC(efi_stub_entry)
+entry_end:
+ENDPROC(entry)
diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S
index 90d09eddd5b2..28a81e948df9 100644
--- a/arch/arm64/kernel/head.S
+++ b/arch/arm64/kernel/head.S
@@ -120,8 +120,8 @@ efi_head:
 #endif
 
 #ifdef CONFIG_EFI
-	.globl	stext_offset
-	.set	stext_offset, stext - efi_head
+	.globl	__efistub_stext_offset
+	.set	__efistub_stext_offset, stext - efi_head
 	.align 3
 pe_header:
 	.ascii	"PE"
@@ -144,8 +144,8 @@ optional_header:
 	.long	_end - stext			// SizeOfCode
 	.long	0				// SizeOfInitializedData
 	.long	0				// SizeOfUninitializedData
-	.long	efi_stub_entry - efi_head	// AddressOfEntryPoint
-	.long	stext_offset			// BaseOfCode
+	.long	__efistub_entry - efi_head	// AddressOfEntryPoint
+	.long	__efistub_stext_offset		// BaseOfCode
 
 extra_header_fields:
 	.quad	0				// ImageBase
@@ -162,7 +162,7 @@ extra_header_fields:
 	.long	_end - efi_head			// SizeOfImage
 
 	// Everything before the kernel image is considered part of the header
-	.long	stext_offset			// SizeOfHeaders
+	.long	__efistub_stext_offset		// SizeOfHeaders
 	.long	0				// CheckSum
 	.short	0xa				// Subsystem (EFI application)
 	.short	0				// DllCharacteristics
@@ -207,9 +207,9 @@ section_table:
 	.byte	0
 	.byte	0        		// end of 0 padding of section name
 	.long	_end - stext		// VirtualSize
-	.long	stext_offset		// VirtualAddress
+	.long	__efistub_stext_offset	// VirtualAddress
 	.long	_edata - stext		// SizeOfRawData
-	.long	stext_offset		// PointerToRawData
+	.long	__efistub_stext_offset	// PointerToRawData
 
 	.long	0		// PointerToRelocations (0 for executables)
 	.long	0		// PointerToLineNumbers (0 for executables)
diff --git a/arch/arm64/kernel/image.h b/arch/arm64/kernel/image.h
index 8fae0756e175..e083af0dd546 100644
--- a/arch/arm64/kernel/image.h
+++ b/arch/arm64/kernel/image.h
@@ -59,4 +59,31 @@
 	_kernel_offset_le	= DATA_LE64(TEXT_OFFSET);	\
 	_kernel_flags_le	= DATA_LE64(__HEAD_FLAGS);
 
+#ifdef CONFIG_EFI
+
+/*
+ * The EFI stub has its own symbol namespace prefixed by __efistub_, to
+ * isolate it from the kernel proper. The following symbols are legally
+ * accessed by the stub, so provide some aliases to make them accessible.
+ * Only include data symbols here, or text symbols of functions that are
+ * guaranteed to be safe when executed at another offset than they were
+ * linked at. The routines below are all implemented in assembler in a
+ * position independent manner
+ */
+__efistub_memcmp		= __pi_memcmp;
+__efistub_memchr		= __pi_memchr;
+__efistub_memcpy		= __pi_memcpy;
+__efistub_memmove		= __pi_memmove;
+__efistub_memset		= __pi_memset;
+__efistub_strlen		= __pi_strlen;
+__efistub_strcmp		= __pi_strcmp;
+__efistub_strncmp		= __pi_strncmp;
+__efistub___flush_dcache_area	= __pi___flush_dcache_area;
+
+__efistub__text			= _text;
+__efistub__end			= _end;
+__efistub__edata		= _edata;
+
+#endif
+
 #endif /* __ASM_IMAGE_H */
diff --git a/drivers/firmware/efi/libstub/Makefile b/drivers/firmware/efi/libstub/Makefile
index 816dbe9f4b82..bca9a76cbd33 100644
--- a/drivers/firmware/efi/libstub/Makefile
+++ b/drivers/firmware/efi/libstub/Makefile
@@ -14,6 +14,8 @@ cflags-$(CONFIG_ARM64)		:= $(subst -pg,,$(KBUILD_CFLAGS))
 cflags-$(CONFIG_ARM)		:= $(subst -pg,,$(KBUILD_CFLAGS)) \
 				   -fno-builtin -fpic -mno-single-pic-base
 
+cflags-$(CONFIG_EFI_ARMSTUB)	+= -I$(srctree)/scripts/dtc/libfdt
+
 KBUILD_CFLAGS			:= $(cflags-y) \
 				   $(call cc-option,-ffreestanding) \
 				   $(call cc-option,-fno-stack-protector)
@@ -22,7 +24,15 @@ GCOV_PROFILE			:= n
 KASAN_SANITIZE			:= n
 
 lib-y				:= efi-stub-helper.o
-lib-$(CONFIG_EFI_ARMSTUB)	+= arm-stub.o fdt.o
+
+# include the stub's generic dependencies from lib/ when building for ARM/arm64
+arm-deps := fdt_rw.c fdt_ro.c fdt_wip.c fdt.c fdt_empty_tree.c fdt_sw.c sort.c
+
+$(obj)/lib-%.o: $(srctree)/lib/%.c FORCE
+	$(call if_changed_rule,cc_o_c)
+
+lib-$(CONFIG_EFI_ARMSTUB)	+= arm-stub.o fdt.o string.o \
+				   $(patsubst %.c,lib-%.o,$(arm-deps))
 
 #
 # arm64 puts the stub in the kernel proper, which will unnecessarily retain all
@@ -30,10 +40,27 @@ lib-$(CONFIG_EFI_ARMSTUB)	+= arm-stub.o fdt.o
 # So let's apply the __init annotations at the section level, by prefixing
 # the section names directly. This will ensure that even all the inline string
 # literals are covered.
+# The fact that the stub and the kernel proper are essentially the same binary
+# also means that we need to be extra careful to make sure that the stub does
+# not rely on any absolute symbol references, considering that the virtual
+# kernel mapping that the linker uses is not active yet when the stub is
+# executing. So build all C dependencies of the EFI stub into libstub, and do
+# a verification pass to see if any absolute relocations exist in any of the
+# object files.
 #
-extra-$(CONFIG_ARM64)		:= $(lib-y)
-lib-$(CONFIG_ARM64)		:= $(patsubst %.o,%.init.o,$(lib-y))
+extra-$(CONFIG_EFI_ARMSTUB)	:= $(lib-y)
+lib-$(CONFIG_EFI_ARMSTUB)	:= $(patsubst %.o,%.stub.o,$(lib-y))
+
+STUBCOPY_FLAGS-y		:= -R .debug* -R *ksymtab*
+STUBCOPY_FLAGS-$(CONFIG_ARM64)	+= --prefix-alloc-sections=.init \
+				   --prefix-symbols=__efistub_
+STUBCOPY_RELOC-$(CONFIG_ARM64)	:= R_AARCH64_ABS
+
+$(obj)/%.stub.o: $(obj)/%.o FORCE
+	$(call if_changed,stubcopy)
 
-OBJCOPYFLAGS := --prefix-alloc-sections=.init
-$(obj)/%.init.o: $(obj)/%.o FORCE
-	$(call if_changed,objcopy)
+quiet_cmd_stubcopy = STUBCPY $@
+      cmd_stubcopy = if $(OBJCOPY) $(STUBCOPY_FLAGS-y) $< $@; then	\
+		     $(OBJDUMP) -r $@ | grep $(STUBCOPY_RELOC-y)	\
+		     && (echo >&2 "$@: absolute symbol references not allowed in the EFI stub"; \
+			 rm -f $@; /bin/false); else /bin/false; fi
diff --git a/drivers/firmware/efi/libstub/string.c b/drivers/firmware/efi/libstub/string.c
new file mode 100644
index 000000000000..09d5a0894343
--- /dev/null
+++ b/drivers/firmware/efi/libstub/string.c
@@ -0,0 +1,57 @@
+/*
+ * Taken from:
+ *  linux/lib/string.c
+ *
+ *  Copyright (C) 1991, 1992  Linus Torvalds
+ */
+
+#include <linux/types.h>
+#include <linux/string.h>
+
+#ifndef __HAVE_ARCH_STRSTR
+/**
+ * strstr - Find the first substring in a %NUL terminated string
+ * @s1: The string to be searched
+ * @s2: The string to search for
+ */
+char *strstr(const char *s1, const char *s2)
+{
+	size_t l1, l2;
+
+	l2 = strlen(s2);
+	if (!l2)
+		return (char *)s1;
+	l1 = strlen(s1);
+	while (l1 >= l2) {
+		l1--;
+		if (!memcmp(s1, s2, l2))
+			return (char *)s1;
+		s1++;
+	}
+	return NULL;
+}
+#endif
+
+#ifndef __HAVE_ARCH_STRNCMP
+/**
+ * strncmp - Compare two length-limited strings
+ * @cs: One string
+ * @ct: Another string
+ * @count: The maximum number of bytes to compare
+ */
+int strncmp(const char *cs, const char *ct, size_t count)
+{
+	unsigned char c1, c2;
+
+	while (count) {
+		c1 = *cs++;
+		c2 = *ct++;
+		if (c1 != c2)
+			return c1 < c2 ? -1 : 1;
+		if (!c1)
+			break;
+		count--;
+	}
+	return 0;
+}
+#endif
-- 
1.9.1

Re: [PATCH v4 3/3] arm64/efi: isolate EFI stub from the kernel proper

[Andrey Ryabinin]

2015-10-08 22:02 GMT+03:00 Ard Biesheuvel <ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>:
> --- a/arch/arm64/kernel/image.h
> +++ b/arch/arm64/kernel/image.h
> @@ -59,4 +59,31 @@
>         _kernel_offset_le       = DATA_LE64(TEXT_OFFSET);       \
>         _kernel_flags_le        = DATA_LE64(__HEAD_FLAGS);
>
> +#ifdef CONFIG_EFI
> +
> +/*
> + * The EFI stub has its own symbol namespace prefixed by __efistub_, to
> + * isolate it from the kernel proper. The following symbols are legally
> + * accessed by the stub, so provide some aliases to make them accessible.
> + * Only include data symbols here, or text symbols of functions that are
> + * guaranteed to be safe when executed at another offset than they were
> + * linked at. The routines below are all implemented in assembler in a
> + * position independent manner
> + */
> +__efistub_memcmp               = __pi_memcmp;
> +__efistub_memchr               = __pi_memchr;
> +__efistub_memcpy               = __pi_memcpy;
> +__efistub_memmove              = __pi_memmove;
> +__efistub_memset               = __pi_memset;
> +__efistub_strlen               = __pi_strlen;
> +__efistub_strcmp               = __pi_strcmp;
> +__efistub_strncmp              = __pi_strncmp;
> +__efistub___flush_dcache_area  = __pi___flush_dcache_area;

So why we need these __pi_* aliases?
We could just do __efistub_memcmp = memcmp; Right?


> +
> +__efistub__text                        = _text;
> +__efistub__end                 = _end;
> +__efistub__edata               = _edata;
> +
> +#endif

Re: [PATCH v4 3/3] arm64/efi: isolate EFI stub from the kernel proper

[Will Deacon]

On Fri, Oct 09, 2015 at 11:12:24AM +0300, Andrey Ryabinin wrote:
> 2015-10-08 22:02 GMT+03:00 Ard Biesheuvel <ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>:
> > --- a/arch/arm64/kernel/image.h
> > +++ b/arch/arm64/kernel/image.h
> > @@ -59,4 +59,31 @@
> >         _kernel_offset_le       = DATA_LE64(TEXT_OFFSET);       \
> >         _kernel_flags_le        = DATA_LE64(__HEAD_FLAGS);
> >
> > +#ifdef CONFIG_EFI
> > +
> > +/*
> > + * The EFI stub has its own symbol namespace prefixed by __efistub_, to
> > + * isolate it from the kernel proper. The following symbols are legally
> > + * accessed by the stub, so provide some aliases to make them accessible.
> > + * Only include data symbols here, or text symbols of functions that are
> > + * guaranteed to be safe when executed at another offset than they were
> > + * linked at. The routines below are all implemented in assembler in a
> > + * position independent manner
> > + */
> > +__efistub_memcmp               = __pi_memcmp;
> > +__efistub_memchr               = __pi_memchr;
> > +__efistub_memcpy               = __pi_memcpy;
> > +__efistub_memmove              = __pi_memmove;
> > +__efistub_memset               = __pi_memset;
> > +__efistub_strlen               = __pi_strlen;
> > +__efistub_strcmp               = __pi_strcmp;
> > +__efistub_strncmp              = __pi_strncmp;
> > +__efistub___flush_dcache_area  = __pi___flush_dcache_area;
> 
> So why we need these __pi_* aliases?
> We could just do __efistub_memcmp = memcmp; Right?

We *could*, but that defeats the whole purpose of tagging
position-independent functions explicitly in the kernel text.

Will

Re: [PATCH v4 3/3] arm64/efi: isolate EFI stub from the kernel proper

[Andrey Ryabinin]

2015-10-09 12:10 GMT+03:00 Will Deacon <will.deacon@arm.com>:
> On Fri, Oct 09, 2015 at 11:12:24AM +0300, Andrey Ryabinin wrote:
>> 2015-10-08 22:02 GMT+03:00 Ard Biesheuvel <ard.biesheuvel@linaro.org>:
>> > --- a/arch/arm64/kernel/image.h
>> > +++ b/arch/arm64/kernel/image.h
>> > @@ -59,4 +59,31 @@
>> >         _kernel_offset_le       = DATA_LE64(TEXT_OFFSET);       \
>> >         _kernel_flags_le        = DATA_LE64(__HEAD_FLAGS);
>> >
>> > +#ifdef CONFIG_EFI
>> > +
>> > +/*
>> > + * The EFI stub has its own symbol namespace prefixed by __efistub_, to
>> > + * isolate it from the kernel proper. The following symbols are legally
>> > + * accessed by the stub, so provide some aliases to make them accessible.
>> > + * Only include data symbols here, or text symbols of functions that are
>> > + * guaranteed to be safe when executed at another offset than they were
>> > + * linked at. The routines below are all implemented in assembler in a
>> > + * position independent manner
>> > + */
>> > +__efistub_memcmp               = __pi_memcmp;
>> > +__efistub_memchr               = __pi_memchr;
>> > +__efistub_memcpy               = __pi_memcpy;
>> > +__efistub_memmove              = __pi_memmove;
>> > +__efistub_memset               = __pi_memset;
>> > +__efistub_strlen               = __pi_strlen;
>> > +__efistub_strcmp               = __pi_strcmp;
>> > +__efistub_strncmp              = __pi_strncmp;
>> > +__efistub___flush_dcache_area  = __pi___flush_dcache_area;
>>
>> So why we need these __pi_* aliases?
>> We could just do __efistub_memcmp = memcmp; Right?
>
> We *could*, but that defeats the whole purpose of tagging
> position-independent functions explicitly in the kernel text.
>

I just don't get that "the whole purpose of tagging".

Yes, the EFI stub is allowed to call only PI kernel functions.
But the EFI stub already protected by __efistub_ namespace.
If we want to use some new PI function in the stub, we would need add
it into this list at first.
So that __pi_ namespace doesn't bring any protection or isolation.

Re: [PATCH v4 3/3] arm64/efi: isolate EFI stub from the kernel proper

[Will Deacon]

On Fri, Oct 09, 2015 at 12:40:21PM +0300, Andrey Ryabinin wrote:
> 2015-10-09 12:10 GMT+03:00 Will Deacon <will.deacon-5wv7dgnIgG8@public.gmane.org>:
> > On Fri, Oct 09, 2015 at 11:12:24AM +0300, Andrey Ryabinin wrote:
> >> 2015-10-08 22:02 GMT+03:00 Ard Biesheuvel <ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>:
> >> > --- a/arch/arm64/kernel/image.h
> >> > +++ b/arch/arm64/kernel/image.h
> >> > @@ -59,4 +59,31 @@
> >> >         _kernel_offset_le       = DATA_LE64(TEXT_OFFSET);       \
> >> >         _kernel_flags_le        = DATA_LE64(__HEAD_FLAGS);
> >> >
> >> > +#ifdef CONFIG_EFI
> >> > +
> >> > +/*
> >> > + * The EFI stub has its own symbol namespace prefixed by __efistub_, to
> >> > + * isolate it from the kernel proper. The following symbols are legally
> >> > + * accessed by the stub, so provide some aliases to make them accessible.
> >> > + * Only include data symbols here, or text symbols of functions that are
> >> > + * guaranteed to be safe when executed at another offset than they were
> >> > + * linked at. The routines below are all implemented in assembler in a
> >> > + * position independent manner
> >> > + */
> >> > +__efistub_memcmp               = __pi_memcmp;
> >> > +__efistub_memchr               = __pi_memchr;
> >> > +__efistub_memcpy               = __pi_memcpy;
> >> > +__efistub_memmove              = __pi_memmove;
> >> > +__efistub_memset               = __pi_memset;
> >> > +__efistub_strlen               = __pi_strlen;
> >> > +__efistub_strcmp               = __pi_strcmp;
> >> > +__efistub_strncmp              = __pi_strncmp;
> >> > +__efistub___flush_dcache_area  = __pi___flush_dcache_area;
> >>
> >> So why we need these __pi_* aliases?
> >> We could just do __efistub_memcmp = memcmp; Right?
> >
> > We *could*, but that defeats the whole purpose of tagging
> > position-independent functions explicitly in the kernel text.
> >
> 
> I just don't get that "the whole purpose of tagging".
> 
> Yes, the EFI stub is allowed to call only PI kernel functions.
> But the EFI stub already protected by __efistub_ namespace.
> If we want to use some new PI function in the stub, we would need add
> it into this list at first.
> So that __pi_ namespace doesn't bring any protection or isolation.

What it does it force people making future changes to the __pi_* functions
to think about the stub, otherwise if the function happens to be
position-independent when efistub starts using it, it could easily break
due to some future patch where the author didn't realise that it was
being used in that manner.

Will

Re: [PATCH v4 3/3] arm64/efi: isolate EFI stub from the kernel proper

[Andrey Ryabinin]

2015-10-09 12:43 GMT+03:00 Will Deacon <will.deacon-5wv7dgnIgG8@public.gmane.org>:
> On Fri, Oct 09, 2015 at 12:40:21PM +0300, Andrey Ryabinin wrote:
>> 2015-10-09 12:10 GMT+03:00 Will Deacon <will.deacon-5wv7dgnIgG8@public.gmane.org>:
>> > On Fri, Oct 09, 2015 at 11:12:24AM +0300, Andrey Ryabinin wrote:
>> >> 2015-10-08 22:02 GMT+03:00 Ard Biesheuvel <ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>:
>> >> > --- a/arch/arm64/kernel/image.h
>> >> > +++ b/arch/arm64/kernel/image.h
>> >> > @@ -59,4 +59,31 @@
>> >> >         _kernel_offset_le       = DATA_LE64(TEXT_OFFSET);       \
>> >> >         _kernel_flags_le        = DATA_LE64(__HEAD_FLAGS);
>> >> >
>> >> > +#ifdef CONFIG_EFI
>> >> > +
>> >> > +/*
>> >> > + * The EFI stub has its own symbol namespace prefixed by __efistub_, to
>> >> > + * isolate it from the kernel proper. The following symbols are legally
>> >> > + * accessed by the stub, so provide some aliases to make them accessible.
>> >> > + * Only include data symbols here, or text symbols of functions that are
>> >> > + * guaranteed to be safe when executed at another offset than they were
>> >> > + * linked at. The routines below are all implemented in assembler in a
>> >> > + * position independent manner
>> >> > + */
>> >> > +__efistub_memcmp               = __pi_memcmp;
>> >> > +__efistub_memchr               = __pi_memchr;
>> >> > +__efistub_memcpy               = __pi_memcpy;
>> >> > +__efistub_memmove              = __pi_memmove;
>> >> > +__efistub_memset               = __pi_memset;
>> >> > +__efistub_strlen               = __pi_strlen;
>> >> > +__efistub_strcmp               = __pi_strcmp;
>> >> > +__efistub_strncmp              = __pi_strncmp;
>> >> > +__efistub___flush_dcache_area  = __pi___flush_dcache_area;
>> >>
>> >> So why we need these __pi_* aliases?
>> >> We could just do __efistub_memcmp = memcmp; Right?
>> >
>> > We *could*, but that defeats the whole purpose of tagging
>> > position-independent functions explicitly in the kernel text.
>> >
>>
>> I just don't get that "the whole purpose of tagging".
>>
>> Yes, the EFI stub is allowed to call only PI kernel functions.
>> But the EFI stub already protected by __efistub_ namespace.
>> If we want to use some new PI function in the stub, we would need add
>> it into this list at first.
>> So that __pi_ namespace doesn't bring any protection or isolation.
>
> What it does it force people making future changes to the __pi_* functions
> to think about the stub, otherwise if the function happens to be
> position-independent when efistub starts using it, it could easily break
> due to some future patch where the author didn't realise that it was
> being used in that manner.
>

That makes sense, thanks.

> Will

Re: [PATCH v4 3/3] arm64/efi: isolate EFI stub from the kernel proper

[Matt Fleming]

On Thu, 08 Oct, at 08:02:04PM, Ard Biesheuvel wrote:
> Since arm64 does not use a builtin decompressor, the EFI stub is built
> into the kernel proper. So far, this has been working fine, but actually,
> since the stub is in fact a PE/COFF relocatable binary that is executed
> at an unknown offset in the 1:1 mapping provided by the UEFI firmware, we
> should not be seamlessly sharing code with the kernel proper, which is a
> position dependent executable linked at a high virtual offset.
> 
> So instead, separate the contents of libstub and its dependencies, by
> putting them into their own namespace by prefixing all of its symbols
> with __efistub. This way, we have tight control over what parts of the
> kernel proper are referenced by the stub.
> 
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> ---
>  arch/arm64/kernel/Makefile            | 12 ++++-
>  arch/arm64/kernel/efi-entry.S         | 10 ++--
>  arch/arm64/kernel/head.S              | 14 ++---
>  arch/arm64/kernel/image.h             | 27 ++++++++++
>  drivers/firmware/efi/libstub/Makefile | 39 +++++++++++---
>  drivers/firmware/efi/libstub/string.c | 57 ++++++++++++++++++++
>  6 files changed, 139 insertions(+), 20 deletions(-)

Reviewed-by: Matt Fleming <matt.fleming-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>

-- 
Matt Fleming, Intel Open Source Technology Center

Re: [PATCH v4 3/3] arm64/efi: isolate EFI stub from the kernel proper

[Jeremy Linton]

On 10/08/2015 02:02 PM, Ard Biesheuvel wrote:
> Since arm64 does not use a builtin decompressor, the EFI stub is built
> into the kernel proper. So far, this has been working fine, but actually,
> since the stub is in fact a PE/COFF relocatable binary that is executed
> at an unknown offset in the 1:1 mapping provided by the UEFI firmware, we
> should not be seamlessly sharing code with the kernel proper, which is a
> position dependent executable linked at a high virtual offset.

This patch appears to be causing a build break

  STUBCPY drivers/firmware/efi/libstub/lib-sort.stub.o
0000000000000000 R_AARCH64_ABS64   __efistub___crc_sort
drivers/firmware/efi/libstub/lib-sort.stub.o: absolute symbol references 
not allowed in the EFI stub

__kcrctab_sort:
	.xword	__crc_sort
	.weak	__crc_sort
	.text


Which is the EXPORT_SYMBOL() in sort.c combined with !CONFIG_MODVERSIONS.

Re: [PATCH v4 3/3] arm64/efi: isolate EFI stub from the kernel proper

[Jeremy Linton]

On 10/26/2015 05:26 PM, Jeremy Linton wrote:
> On 10/08/2015 02:02 PM, Ard Biesheuvel wrote:
>> Since arm64 does not use a builtin decompressor, the EFI stub is built
>> into the kernel proper. So far, this has been working fine, but actually,
>> since the stub is in fact a PE/COFF relocatable binary that is executed
>> at an unknown offset in the 1:1 mapping provided by the UEFI firmware, we
>> should not be seamlessly sharing code with the kernel proper, which is a
>> position dependent executable linked at a high virtual offset.
>
> This patch appears to be causing a build break
>
>   STUBCPY drivers/firmware/efi/libstub/lib-sort.stub.o
> 0000000000000000 R_AARCH64_ABS64   __efistub___crc_sort
> drivers/firmware/efi/libstub/lib-sort.stub.o: absolute symbol references
> not allowed in the EFI stub
>
> __kcrctab_sort:
>      .xword    __crc_sort
>      .weak    __crc_sort
>      .text
>
>
> Which is the EXPORT_SYMBOL() in sort.c combined with !CONFIG_MODVERSIONS.

	Sorry, I that should be CONFIG_MODVERSIONS..

Re: [PATCH v4 3/3] arm64/efi: isolate EFI stub from the kernel proper

[Ard Biesheuvel]

On 27 October 2015 at 07:33, Jeremy Linton <jeremy.linton-5wv7dgnIgG8@public.gmane.org> wrote:
> On 10/26/2015 05:26 PM, Jeremy Linton wrote:
>>
>> On 10/08/2015 02:02 PM, Ard Biesheuvel wrote:
>>>
>>> Since arm64 does not use a builtin decompressor, the EFI stub is built
>>> into the kernel proper. So far, this has been working fine, but actually,
>>> since the stub is in fact a PE/COFF relocatable binary that is executed
>>> at an unknown offset in the 1:1 mapping provided by the UEFI firmware, we
>>> should not be seamlessly sharing code with the kernel proper, which is a
>>> position dependent executable linked at a high virtual offset.
>>
>>
>> This patch appears to be causing a build break
>>
>>   STUBCPY drivers/firmware/efi/libstub/lib-sort.stub.o
>> 0000000000000000 R_AARCH64_ABS64   __efistub___crc_sort
>> drivers/firmware/efi/libstub/lib-sort.stub.o: absolute symbol references
>> not allowed in the EFI stub
>>
>> __kcrctab_sort:
>>      .xword    __crc_sort
>>      .weak    __crc_sort
>>      .text
>>
>>
>> Which is the EXPORT_SYMBOL() in sort.c combined with !CONFIG_MODVERSIONS.
>
>
>         Sorry, I that should be CONFIG_MODVERSIONS..
>

Hi Jeremy,

Thanks for the report. The following patch should fix it

-----------------8<----------------
>From 1179099f89db54294f419493d152083fb8e5af3d Mon Sep 17 00:00:00 2001
From: Ard Biesheuvel <ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Date: Tue, 27 Oct 2015 11:12:51 +0900
Subject: [PATCH] arm64/efi: fix libstub build under CONFIG_MODVERSIONS

Now that we strictly forbid absolute relocations in libstub code,
make sure that we don't emit any when CONFIG_MODVERSIONS is enabled,
by stripping the kcrctab sections from the object file. This fixes
a build problem under CONFIG_MODVERSIONS=y.

Signed-off-by: Ard Biesheuvel <ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
---
 drivers/firmware/efi/libstub/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/firmware/efi/libstub/Makefile
b/drivers/firmware/efi/libstub/Makefile
index bca9a76cbd33..acc25d7c5da2 100644
--- a/drivers/firmware/efi/libstub/Makefile
+++ b/drivers/firmware/efi/libstub/Makefile
@@ -51,7 +51,7 @@ lib-$(CONFIG_EFI_ARMSTUB) += arm-stub.o fdt.o string.o \
 extra-$(CONFIG_EFI_ARMSTUB) := $(lib-y)
 lib-$(CONFIG_EFI_ARMSTUB) := $(patsubst %.o,%.stub.o,$(lib-y))

-STUBCOPY_FLAGS-y := -R .debug* -R *ksymtab*
+STUBCOPY_FLAGS-y := -R .debug* -R *ksymtab* -R *kcrctab*
 STUBCOPY_FLAGS-$(CONFIG_ARM64) += --prefix-alloc-sections=.init \
    --prefix-symbols=__efistub_
 STUBCOPY_RELOC-$(CONFIG_ARM64) := R_AARCH64_ABS
-- 
2.1.4

Re: [PATCH v4 3/3] arm64/efi: isolate EFI stub from the kernel proper

[Jeremy Linton]

On 10/26/2015 09:20 PM, Ard Biesheuvel wrote:
> Thanks for the report. The following patch should fix it

Ard,
	
Thanks, it does fix the build problem...

Now to get the darn thing to boot (not related to this AFAIK).



	

Re: [PATCH v4 3/3] arm64/efi: isolate EFI stub from the kernel proper

[Ard Biesheuvel]

On 27 October 2015 at 23:44, Jeremy Linton <jeremy.linton-5wv7dgnIgG8@public.gmane.org> wrote:
> On 10/26/2015 09:20 PM, Ard Biesheuvel wrote:
>>
>> Thanks for the report. The following patch should fix it
>
>
> Ard,
>
> Thanks, it does fix the build problem...
>
> Now to get the darn thing to boot (not related to this AFAIK).
>

Catalin,

Would you like me to resend this as a separate patch?

-- 
Ard.

Re: [PATCH v4 3/3] arm64/efi: isolate EFI stub from the kernel proper

[Mark Rutland]

[Adding Catalin to the To line]

On Fri, Oct 30, 2015 at 01:17:24PM +0100, Ard Biesheuvel wrote:
> On 27 October 2015 at 23:44, Jeremy Linton <jeremy.linton-5wv7dgnIgG8@public.gmane.org> wrote:
> > On 10/26/2015 09:20 PM, Ard Biesheuvel wrote:
> >>
> >> Thanks for the report. The following patch should fix it
> >
> >
> > Ard,
> >
> > Thanks, it does fix the build problem...
> >
> > Now to get the darn thing to boot (not related to this AFAIK).
> >
> 
> Catalin,
> 
> Would you like me to resend this as a separate patch?

Ard's referring to the patch in a prior reply [1].

Mark.

[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2015-October/381074.html

Re: [PATCH v4 3/3] arm64/efi: isolate EFI stub from the kernel proper

[Catalin Marinas]

On Fri, Oct 30, 2015 at 01:17:24PM +0100, Ard Biesheuvel wrote:
> On 27 October 2015 at 23:44, Jeremy Linton <jeremy.linton-5wv7dgnIgG8@public.gmane.org> wrote:
> > On 10/26/2015 09:20 PM, Ard Biesheuvel wrote:
> >>
> >> Thanks for the report. The following patch should fix it
> >
> >
> > Ard,
> >
> > Thanks, it does fix the build problem...
> >
> > Now to get the darn thing to boot (not related to this AFAIK).
> 
> Would you like me to resend this as a separate patch?

No need to but it would be good to get an Ack from Matt since it touches
drivers/firmware/efi/libstub/Makefile (the patch introducing
STUBCOPY_FLAGS was already acked).

-- 
Catalin

Re: [PATCH v4 3/3] arm64/efi: isolate EFI stub from the kernel proper

[Matt Fleming]

On Tue, 27 Oct, at 11:20:51AM, Ard Biesheuvel wrote:
> From 1179099f89db54294f419493d152083fb8e5af3d Mon Sep 17 00:00:00 2001
> From: Ard Biesheuvel <ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> Date: Tue, 27 Oct 2015 11:12:51 +0900
> Subject: [PATCH] arm64/efi: fix libstub build under CONFIG_MODVERSIONS
> 
> Now that we strictly forbid absolute relocations in libstub code,
> make sure that we don't emit any when CONFIG_MODVERSIONS is enabled,
> by stripping the kcrctab sections from the object file. This fixes
> a build problem under CONFIG_MODVERSIONS=y.
> 
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> ---
>  drivers/firmware/efi/libstub/Makefile | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/firmware/efi/libstub/Makefile
> b/drivers/firmware/efi/libstub/Makefile
> index bca9a76cbd33..acc25d7c5da2 100644
> --- a/drivers/firmware/efi/libstub/Makefile
> +++ b/drivers/firmware/efi/libstub/Makefile
> @@ -51,7 +51,7 @@ lib-$(CONFIG_EFI_ARMSTUB) += arm-stub.o fdt.o string.o \
>  extra-$(CONFIG_EFI_ARMSTUB) := $(lib-y)
>  lib-$(CONFIG_EFI_ARMSTUB) := $(patsubst %.o,%.stub.o,$(lib-y))
> 
> -STUBCOPY_FLAGS-y := -R .debug* -R *ksymtab*
> +STUBCOPY_FLAGS-y := -R .debug* -R *ksymtab* -R *kcrctab*
>  STUBCOPY_FLAGS-$(CONFIG_ARM64) += --prefix-alloc-sections=.init \
>     --prefix-symbols=__efistub_
>  STUBCOPY_RELOC-$(CONFIG_ARM64) := R_AARCH64_ABS

I *think* this should be OK.

Reviewed-by: Matt Fleming <matt-mF/unelCI9GS6iBeEJttW/XRex20P6io@public.gmane.org>

Re: [PATCH v4 3/3] arm64/efi: isolate EFI stub from the kernel proper

[Robert Richter]

Ard,

On 08.10.15 20:02:04, Ard Biesheuvel wrote:
> +quiet_cmd_stubcopy = STUBCPY $@
> +      cmd_stubcopy = if $(OBJCOPY) $(STUBCOPY_FLAGS-y) $< $@; then	\
> +		     $(OBJDUMP) -r $@ | grep $(STUBCOPY_RELOC-y)	\
> +		     && (echo >&2 "$@: absolute symbol references not allowed in the EFI stub"; \
> +			 rm -f $@; /bin/false); else /bin/false; fi

This one is causing some more build errors for my setup. Any hint how
to fix that?

Thanks,

-Robert


  STUBCPY drivers/firmware/efi/libstub/arm-stub.stub.o
0000000000000006 R_AARCH64_ABS32   .debug_abbrev
000000000000000c R_AARCH64_ABS32   .debug_str+0x0000000000000890
0000000000000011 R_AARCH64_ABS32   .debug_str+0x0000000000004ecd
0000000000000015 R_AARCH64_ABS32   .debug_str+0x0000000000000bb1
0000000000000019 R_AARCH64_ABS64   .init.text
0000000000000021 R_AARCH64_ABS64   .init.text+0x00000000000008cc
0000000000000029 R_AARCH64_ABS32   .debug_line
0000000000000030 R_AARCH64_ABS32   .debug_str+0x00000000000000eb
0000000000000047 R_AARCH64_ABS32   .debug_str+0x0000000000003ca8
0000000000000059 R_AARCH64_ABS32   .debug_str+0x0000000000004798
0000000000000060 R_AARCH64_ABS32   .debug_str+0x0000000000005008
...
000000000000a4bb R_AARCH64_ABS32   .debug_str+0x0000000000004a75
000000000000a4da R_AARCH64_ABS32   .debug_str+0x00000000000029ee
000000000000a4f7 R_AARCH64_ABS32   .debug_str+0x0000000000001d95
000000000000a519 R_AARCH64_ABS32   .debug_str+0x0000000000000773
0000000000000006 R_AARCH64_ABS32   .debug_info
0000000000000010 R_AARCH64_ABS64   .init.text
0000000000000623 R_AARCH64_ABS64   .init.text
0000000000000014 R_AARCH64_ABS32   .debug_frame
0000000000000018 R_AARCH64_ABS64   .init.text
000000000000002c R_AARCH64_ABS32   .debug_frame
0000000000000030 R_AARCH64_ABS64   .init.text+0x0000000000000018
0000000000000074 R_AARCH64_ABS32   .debug_frame
0000000000000078 R_AARCH64_ABS64   .init.text+0x0000000000000140
000000000000009c R_AARCH64_ABS32   .debug_frame
00000000000000a0 R_AARCH64_ABS64   .init.text+0x0000000000000158
00000000000000c4 R_AARCH64_ABS32   .debug_frame
00000000000000c8 R_AARCH64_ABS64   .init.text+0x0000000000000170
000000000000012c R_AARCH64_ABS32   .debug_frame
0000000000000130 R_AARCH64_ABS64   .init.text+0x0000000000000390
0000000000000154 R_AARCH64_ABS32   .debug_frame
0000000000000158 R_AARCH64_ABS64   .init.text+0x00000000000003b0
00000000000001a4 R_AARCH64_ABS32   .debug_frame
00000000000001a8 R_AARCH64_ABS64   .init.text+0x0000000000000780
drivers/firmware/efi/libstub/arm-stub.stub.o: absolute symbol references not allowed in the EFI stub

Re: [PATCH v4 3/3] arm64/efi: isolate EFI stub from the kernel proper

[Ard Biesheuvel]

On 24 November 2015 at 10:34, Robert Richter
<robert.richter-M3mlKVOIwJVv6pq1l3V1OdBPR1lH4CV8@public.gmane.org> wrote:
> Ard,
>
> On 08.10.15 20:02:04, Ard Biesheuvel wrote:
>> +quiet_cmd_stubcopy = STUBCPY $@
>> +      cmd_stubcopy = if $(OBJCOPY) $(STUBCOPY_FLAGS-y) $< $@; then   \
>> +                  $(OBJDUMP) -r $@ | grep $(STUBCOPY_RELOC-y)        \
>> +                  && (echo >&2 "$@: absolute symbol references not allowed in the EFI stub"; \
>> +                      rm -f $@; /bin/false); else /bin/false; fi
>
> This one is causing some more build errors for my setup. Any hint how
> to fix that?
>

Did you remove -R .debug* from the STUBCOPY_FLAGS-$(CONFIG_ARM64) line?

The problem here is that
a) .debug contains absolute relocations, which is harmless by itself
since they are not used by the program itself, but
b) the .debug sections also contain references to the ksymtab and
kcrctab sections, which should be removed, and removing those and
keeping .debug* sadly doesn't work.

-- 
Ard.


>
>   STUBCPY drivers/firmware/efi/libstub/arm-stub.stub.o
> 0000000000000006 R_AARCH64_ABS32   .debug_abbrev
> 000000000000000c R_AARCH64_ABS32   .debug_str+0x0000000000000890
> 0000000000000011 R_AARCH64_ABS32   .debug_str+0x0000000000004ecd
> 0000000000000015 R_AARCH64_ABS32   .debug_str+0x0000000000000bb1
> 0000000000000019 R_AARCH64_ABS64   .init.text
> 0000000000000021 R_AARCH64_ABS64   .init.text+0x00000000000008cc
> 0000000000000029 R_AARCH64_ABS32   .debug_line
> 0000000000000030 R_AARCH64_ABS32   .debug_str+0x00000000000000eb
> 0000000000000047 R_AARCH64_ABS32   .debug_str+0x0000000000003ca8
> 0000000000000059 R_AARCH64_ABS32   .debug_str+0x0000000000004798
> 0000000000000060 R_AARCH64_ABS32   .debug_str+0x0000000000005008
> ...
> 000000000000a4bb R_AARCH64_ABS32   .debug_str+0x0000000000004a75
> 000000000000a4da R_AARCH64_ABS32   .debug_str+0x00000000000029ee
> 000000000000a4f7 R_AARCH64_ABS32   .debug_str+0x0000000000001d95
> 000000000000a519 R_AARCH64_ABS32   .debug_str+0x0000000000000773
> 0000000000000006 R_AARCH64_ABS32   .debug_info
> 0000000000000010 R_AARCH64_ABS64   .init.text
> 0000000000000623 R_AARCH64_ABS64   .init.text
> 0000000000000014 R_AARCH64_ABS32   .debug_frame
> 0000000000000018 R_AARCH64_ABS64   .init.text
> 000000000000002c R_AARCH64_ABS32   .debug_frame
> 0000000000000030 R_AARCH64_ABS64   .init.text+0x0000000000000018
> 0000000000000074 R_AARCH64_ABS32   .debug_frame
> 0000000000000078 R_AARCH64_ABS64   .init.text+0x0000000000000140
> 000000000000009c R_AARCH64_ABS32   .debug_frame
> 00000000000000a0 R_AARCH64_ABS64   .init.text+0x0000000000000158
> 00000000000000c4 R_AARCH64_ABS32   .debug_frame
> 00000000000000c8 R_AARCH64_ABS64   .init.text+0x0000000000000170
> 000000000000012c R_AARCH64_ABS32   .debug_frame
> 0000000000000130 R_AARCH64_ABS64   .init.text+0x0000000000000390
> 0000000000000154 R_AARCH64_ABS32   .debug_frame
> 0000000000000158 R_AARCH64_ABS64   .init.text+0x00000000000003b0
> 00000000000001a4 R_AARCH64_ABS32   .debug_frame
> 00000000000001a8 R_AARCH64_ABS64   .init.text+0x0000000000000780
> drivers/firmware/efi/libstub/arm-stub.stub.o: absolute symbol references not allowed in the EFI stub

Re: [PATCH v4 0/3] arm64: EFI stub isolation

[Matt Fleming]

On Thu, 08 Oct, at 08:02:01PM, Ard Biesheuvel wrote:
> We need to ensure that the EFI stub only uses parts of the kernel proper
> that are safe to use when the kernel virtual mapping is not active yet.
> 
> So move all C code dependencies to the libstub, which is built with all
> instrumentation (gcov, kasan) disabled, and do a verification pass to
> ensure that no absolute relocations are used.
> 
> On the arm64 side, annotate all the stub's dependencies as safe for PI
> (position independent
> 
> @Matt: if you are OK with these, may we please have your ack on patches #1 and
> #2 so that Catalin can pick up the series? Thanks.

I assumed you meant PATCH 1 and PATCH 3. If so, yeah, these look fine
to be taken through Catalin's tree.

-- 
Matt Fleming, Intel Open Source Technology Center

Re: [PATCH v4 0/3] arm64: EFI stub isolation

[Catalin Marinas]

On Sat, Oct 10, 2015 at 11:40:51PM +0100, Matt Fleming wrote:
> On Thu, 08 Oct, at 08:02:01PM, Ard Biesheuvel wrote:
> > We need to ensure that the EFI stub only uses parts of the kernel proper
> > that are safe to use when the kernel virtual mapping is not active yet.
> > 
> > So move all C code dependencies to the libstub, which is built with all
> > instrumentation (gcov, kasan) disabled, and do a verification pass to
> > ensure that no absolute relocations are used.
> > 
> > On the arm64 side, annotate all the stub's dependencies as safe for PI
> > (position independent
> > 
> > @Matt: if you are OK with these, may we please have your ack on patches #1 and
> > #2 so that Catalin can pick up the series? Thanks.
> 
> I assumed you meant PATCH 1 and PATCH 3. If so, yeah, these look fine
> to be taken through Catalin's tree.

Thanks for the review. Patches queued for 4.4.

-- 
Catalin