* [PATCH] efi: zboot: Ensure zboot PIC
@ 2023-03-27 9:51 Pingfan Liu
2023-03-27 10:57 ` Ard Biesheuvel
0 siblings, 1 reply; 7+ messages in thread
From: Pingfan Liu @ 2023-03-27 9:51 UTC (permalink / raw)
To: linux-efi
Cc: Pingfan Liu, Ard Biesheuvel, Kees Cook, Catalin Marinas,
Sami Tolvanen, Huacai Chen
Using objcopy to reform vmlinuz.efi.elf to vmlinuz.efi will not convey
any relocation information. That means vmlinuz.efi is expected to be
PIC.
At present, vmlinuz.efi is PIC. But it is better to adopt the same
solution used by the kernel to resolve the code relocation issue by
itself. That is to resolve R_AARCH64_RELATIVE at the runtime.
Signed-off-by: Pingfan Liu <kernelfans@gmail.com>
Cc: Ard Biesheuvel <ardb@kernel.org>
Cc: Kees Cook <keescook@chromium.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Sami Tolvanen <samitolvanen@google.com>
Cc: Huacai Chen <chenhuacai@kernel.org>
To: linux-efi@vger.kernel.org
---
drivers/firmware/efi/libstub/Makefile | 2 +-
drivers/firmware/efi/libstub/Makefile.zboot | 2 +-
drivers/firmware/efi/libstub/zboot-entry.S | 35 +++++++++++++++++++++
drivers/firmware/efi/libstub/zboot.c | 2 +-
drivers/firmware/efi/libstub/zboot.lds | 6 ++++
5 files changed, 44 insertions(+), 3 deletions(-)
create mode 100644 drivers/firmware/efi/libstub/zboot-entry.S
diff --git a/drivers/firmware/efi/libstub/Makefile b/drivers/firmware/efi/libstub/Makefile
index 80d85a5169fb..4447395d7218 100644
--- a/drivers/firmware/efi/libstub/Makefile
+++ b/drivers/firmware/efi/libstub/Makefile
@@ -95,7 +95,7 @@ lib-$(CONFIG_LOONGARCH) += loongarch.o loongarch-stub.o
CFLAGS_arm32-stub.o := -DTEXT_OFFSET=$(TEXT_OFFSET)
zboot-obj-$(CONFIG_RISCV) := lib-clz_ctz.o lib-ashldi3.o
-lib-$(CONFIG_EFI_ZBOOT) += zboot.o $(zboot-obj-y)
+lib-$(CONFIG_EFI_ZBOOT) += zboot-entry.o zboot.o $(zboot-obj-y)
extra-y := $(lib-y)
lib-y := $(patsubst %.o,%.stub.o,$(lib-y))
diff --git a/drivers/firmware/efi/libstub/Makefile.zboot b/drivers/firmware/efi/libstub/Makefile.zboot
index 43e9a4cab9f5..1ed948cee92f 100644
--- a/drivers/firmware/efi/libstub/Makefile.zboot
+++ b/drivers/firmware/efi/libstub/Makefile.zboot
@@ -36,7 +36,7 @@ $(obj)/zboot-header.o: $(srctree)/drivers/firmware/efi/libstub/zboot-header.S FO
ZBOOT_DEPS := $(obj)/zboot-header.o $(objtree)/drivers/firmware/efi/libstub/lib.a
-LDFLAGS_vmlinuz.efi.elf := -T $(srctree)/drivers/firmware/efi/libstub/zboot.lds
+LDFLAGS_vmlinuz.efi.elf := --no-undefined -X -shared -Bsymbolic -z notext --no-apply-dynamic-relocs -T $(srctree)/drivers/firmware/efi/libstub/zboot.lds
$(obj)/vmlinuz.efi.elf: $(obj)/vmlinuz.o $(ZBOOT_DEPS) FORCE
$(call if_changed,ld)
diff --git a/drivers/firmware/efi/libstub/zboot-entry.S b/drivers/firmware/efi/libstub/zboot-entry.S
new file mode 100644
index 000000000000..072207f2f6ba
--- /dev/null
+++ b/drivers/firmware/efi/libstub/zboot-entry.S
@@ -0,0 +1,35 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+
+#include <asm/elf.h>
+#define ZBOOT_HEADER_BASE 0
+
+ .text
+/*
+ * x0: efi_handle_t
+ * x1: efi_system_table_t *
+ */
+ .global efi_zboot_entry
+efi_zboot_entry:
+ adrp x2, efi_zboot_header
+ add x2, x2, :lo12:efi_zboot_header
+ mov x3, ZBOOT_HEADER_BASE
+ sub x3, x2, x3 // delta between actual and linked address
+ adrp x4, _rela_start
+ add x4, x4, :lo12:_rela_start
+ adrp x5, _rela_end
+ add x5, x5, :lo12:_rela_end
+
+0: cmp x5, x4
+ b.hs 1f
+ ldp x6, x7, [x4], #24
+ ldr x8, [x4, #-8]
+ cmp w7, #R_AARCH64_RELATIVE
+ b.ne 0b
+ add x8, x8, x3
+ str x8, [x6, x3]
+ b 0b
+
+1:
+ dsb ishst
+ ic iallu
+ b efi_zboot_main
diff --git a/drivers/firmware/efi/libstub/zboot.c b/drivers/firmware/efi/libstub/zboot.c
index ba234e062a1a..7aa6b2e6d104 100644
--- a/drivers/firmware/efi/libstub/zboot.c
+++ b/drivers/firmware/efi/libstub/zboot.c
@@ -58,7 +58,7 @@ void __weak efi_cache_sync_image(unsigned long image_base,
}
asmlinkage efi_status_t __efiapi
-efi_zboot_entry(efi_handle_t handle, efi_system_table_t *systab)
+efi_zboot_main(efi_handle_t handle, efi_system_table_t *systab)
{
unsigned long compressed_size = _gzdata_end - _gzdata_start;
unsigned long image_base, alloc_size, code_size;
diff --git a/drivers/firmware/efi/libstub/zboot.lds b/drivers/firmware/efi/libstub/zboot.lds
index 93d33f68333b..631942604c3f 100644
--- a/drivers/firmware/efi/libstub/zboot.lds
+++ b/drivers/firmware/efi/libstub/zboot.lds
@@ -12,6 +12,12 @@ SECTIONS
*(.text* .init.text*)
}
+ .rela.dyn : ALIGN(8) {
+ __efistub__rela_start = .;
+ *(.rela .rela*)
+ __efistub__rela_end = .;
+ }
+
.rodata : ALIGN(8) {
__efistub__gzdata_start = .;
*(.gzdata)
--
2.31.1
^ permalink raw reply related [flat|nested] 7+ messages in thread* Re: [PATCH] efi: zboot: Ensure zboot PIC
2023-03-27 9:51 [PATCH] efi: zboot: Ensure zboot PIC Pingfan Liu
@ 2023-03-27 10:57 ` Ard Biesheuvel
2023-03-28 7:32 ` Pingfan Liu
0 siblings, 1 reply; 7+ messages in thread
From: Ard Biesheuvel @ 2023-03-27 10:57 UTC (permalink / raw)
To: Pingfan Liu
Cc: linux-efi, Kees Cook, Catalin Marinas, Sami Tolvanen, Huacai Chen
On Mon, 27 Mar 2023 at 11:51, Pingfan Liu <kernelfans@gmail.com> wrote:
>
> Using objcopy to reform vmlinuz.efi.elf to vmlinuz.efi will not convey
> any relocation information. That means vmlinuz.efi is expected to be
> PIC.
>
> At present, vmlinuz.efi is PIC. But it is better to adopt the same
Why is it better?
> solution used by the kernel to resolve the code relocation issue by
> itself. That is to resolve R_AARCH64_RELATIVE at the runtime.
>
This breaks other architectures.
> Signed-off-by: Pingfan Liu <kernelfans@gmail.com>
> Cc: Ard Biesheuvel <ardb@kernel.org>
> Cc: Kees Cook <keescook@chromium.org>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Sami Tolvanen <samitolvanen@google.com>
> Cc: Huacai Chen <chenhuacai@kernel.org>
> To: linux-efi@vger.kernel.org
> ---
> drivers/firmware/efi/libstub/Makefile | 2 +-
> drivers/firmware/efi/libstub/Makefile.zboot | 2 +-
> drivers/firmware/efi/libstub/zboot-entry.S | 35 +++++++++++++++++++++
> drivers/firmware/efi/libstub/zboot.c | 2 +-
> drivers/firmware/efi/libstub/zboot.lds | 6 ++++
> 5 files changed, 44 insertions(+), 3 deletions(-)
> create mode 100644 drivers/firmware/efi/libstub/zboot-entry.S
>
> diff --git a/drivers/firmware/efi/libstub/Makefile b/drivers/firmware/efi/libstub/Makefile
> index 80d85a5169fb..4447395d7218 100644
> --- a/drivers/firmware/efi/libstub/Makefile
> +++ b/drivers/firmware/efi/libstub/Makefile
> @@ -95,7 +95,7 @@ lib-$(CONFIG_LOONGARCH) += loongarch.o loongarch-stub.o
> CFLAGS_arm32-stub.o := -DTEXT_OFFSET=$(TEXT_OFFSET)
>
> zboot-obj-$(CONFIG_RISCV) := lib-clz_ctz.o lib-ashldi3.o
> -lib-$(CONFIG_EFI_ZBOOT) += zboot.o $(zboot-obj-y)
> +lib-$(CONFIG_EFI_ZBOOT) += zboot-entry.o zboot.o $(zboot-obj-y)
>
> extra-y := $(lib-y)
> lib-y := $(patsubst %.o,%.stub.o,$(lib-y))
> diff --git a/drivers/firmware/efi/libstub/Makefile.zboot b/drivers/firmware/efi/libstub/Makefile.zboot
> index 43e9a4cab9f5..1ed948cee92f 100644
> --- a/drivers/firmware/efi/libstub/Makefile.zboot
> +++ b/drivers/firmware/efi/libstub/Makefile.zboot
> @@ -36,7 +36,7 @@ $(obj)/zboot-header.o: $(srctree)/drivers/firmware/efi/libstub/zboot-header.S FO
>
> ZBOOT_DEPS := $(obj)/zboot-header.o $(objtree)/drivers/firmware/efi/libstub/lib.a
>
> -LDFLAGS_vmlinuz.efi.elf := -T $(srctree)/drivers/firmware/efi/libstub/zboot.lds
> +LDFLAGS_vmlinuz.efi.elf := --no-undefined -X -shared -Bsymbolic -z notext --no-apply-dynamic-relocs -T $(srctree)/drivers/firmware/efi/libstub/zboot.lds
> $(obj)/vmlinuz.efi.elf: $(obj)/vmlinuz.o $(ZBOOT_DEPS) FORCE
> $(call if_changed,ld)
>
> diff --git a/drivers/firmware/efi/libstub/zboot-entry.S b/drivers/firmware/efi/libstub/zboot-entry.S
> new file mode 100644
> index 000000000000..072207f2f6ba
> --- /dev/null
> +++ b/drivers/firmware/efi/libstub/zboot-entry.S
> @@ -0,0 +1,35 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +
> +#include <asm/elf.h>
> +#define ZBOOT_HEADER_BASE 0
> +
> + .text
> +/*
> + * x0: efi_handle_t
> + * x1: efi_system_table_t *
> + */
> + .global efi_zboot_entry
> +efi_zboot_entry:
> + adrp x2, efi_zboot_header
> + add x2, x2, :lo12:efi_zboot_header
> + mov x3, ZBOOT_HEADER_BASE
> + sub x3, x2, x3 // delta between actual and linked address
> + adrp x4, _rela_start
> + add x4, x4, :lo12:_rela_start
> + adrp x5, _rela_end
> + add x5, x5, :lo12:_rela_end
> +
> +0: cmp x5, x4
> + b.hs 1f
> + ldp x6, x7, [x4], #24
> + ldr x8, [x4, #-8]
> + cmp w7, #R_AARCH64_RELATIVE
> + b.ne 0b
> + add x8, x8, x3
> + str x8, [x6, x3]
> + b 0b
> +
> +1:
> + dsb ishst
> + ic iallu
> + b efi_zboot_main
> diff --git a/drivers/firmware/efi/libstub/zboot.c b/drivers/firmware/efi/libstub/zboot.c
> index ba234e062a1a..7aa6b2e6d104 100644
> --- a/drivers/firmware/efi/libstub/zboot.c
> +++ b/drivers/firmware/efi/libstub/zboot.c
> @@ -58,7 +58,7 @@ void __weak efi_cache_sync_image(unsigned long image_base,
> }
>
> asmlinkage efi_status_t __efiapi
> -efi_zboot_entry(efi_handle_t handle, efi_system_table_t *systab)
> +efi_zboot_main(efi_handle_t handle, efi_system_table_t *systab)
> {
> unsigned long compressed_size = _gzdata_end - _gzdata_start;
> unsigned long image_base, alloc_size, code_size;
> diff --git a/drivers/firmware/efi/libstub/zboot.lds b/drivers/firmware/efi/libstub/zboot.lds
> index 93d33f68333b..631942604c3f 100644
> --- a/drivers/firmware/efi/libstub/zboot.lds
> +++ b/drivers/firmware/efi/libstub/zboot.lds
> @@ -12,6 +12,12 @@ SECTIONS
> *(.text* .init.text*)
> }
>
> + .rela.dyn : ALIGN(8) {
> + __efistub__rela_start = .;
> + *(.rela .rela*)
> + __efistub__rela_end = .;
> + }
> +
> .rodata : ALIGN(8) {
> __efistub__gzdata_start = .;
> *(.gzdata)
> --
> 2.31.1
>
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: [PATCH] efi: zboot: Ensure zboot PIC
2023-03-27 10:57 ` Ard Biesheuvel
@ 2023-03-28 7:32 ` Pingfan Liu
2023-03-28 7:58 ` Ard Biesheuvel
0 siblings, 1 reply; 7+ messages in thread
From: Pingfan Liu @ 2023-03-28 7:32 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: linux-efi, Kees Cook, Catalin Marinas, Sami Tolvanen, Huacai Chen
On Mon, Mar 27, 2023 at 6:57 PM Ard Biesheuvel <ardb@kernel.org> wrote:
>
> On Mon, 27 Mar 2023 at 11:51, Pingfan Liu <kernelfans@gmail.com> wrote:
> >
> > Using objcopy to reform vmlinuz.efi.elf to vmlinuz.efi will not convey
> > any relocation information. That means vmlinuz.efi is expected to be
> > PIC.
> >
> > At present, vmlinuz.efi is PIC. But it is better to adopt the same
>
> Why is it better?
>
I think except carefully coded with asm language, there is no
guarantee which prevents the compiler from generating position
dependent code. Or is there any presumption here?
> > solution used by the kernel to resolve the code relocation issue by
> > itself. That is to resolve R_AARCH64_RELATIVE at the runtime.
> >
>
> This breaks other architectures.
>
Oops, could it be done by:
#if defined(_aarch64_)
#define R_ARCH_RELATIVE R_AARCH64_RELATIVE
#else
#define R_ARCH_RELATIVE 0
#endif
Since any r_type equaling 0 can not be ejected into the relocation
section, this macro will make the code dummy in essential.
Thanks,
Pingfan
> > Signed-off-by: Pingfan Liu <kernelfans@gmail.com>
> > Cc: Ard Biesheuvel <ardb@kernel.org>
> > Cc: Kees Cook <keescook@chromium.org>
> > Cc: Catalin Marinas <catalin.marinas@arm.com>
> > Cc: Sami Tolvanen <samitolvanen@google.com>
> > Cc: Huacai Chen <chenhuacai@kernel.org>
> > To: linux-efi@vger.kernel.org
>
>
> > ---
> > drivers/firmware/efi/libstub/Makefile | 2 +-
> > drivers/firmware/efi/libstub/Makefile.zboot | 2 +-
> > drivers/firmware/efi/libstub/zboot-entry.S | 35 +++++++++++++++++++++
> > drivers/firmware/efi/libstub/zboot.c | 2 +-
> > drivers/firmware/efi/libstub/zboot.lds | 6 ++++
> > 5 files changed, 44 insertions(+), 3 deletions(-)
> > create mode 100644 drivers/firmware/efi/libstub/zboot-entry.S
> >
> > diff --git a/drivers/firmware/efi/libstub/Makefile b/drivers/firmware/efi/libstub/Makefile
> > index 80d85a5169fb..4447395d7218 100644
> > --- a/drivers/firmware/efi/libstub/Makefile
> > +++ b/drivers/firmware/efi/libstub/Makefile
> > @@ -95,7 +95,7 @@ lib-$(CONFIG_LOONGARCH) += loongarch.o loongarch-stub.o
> > CFLAGS_arm32-stub.o := -DTEXT_OFFSET=$(TEXT_OFFSET)
> >
> > zboot-obj-$(CONFIG_RISCV) := lib-clz_ctz.o lib-ashldi3.o
> > -lib-$(CONFIG_EFI_ZBOOT) += zboot.o $(zboot-obj-y)
> > +lib-$(CONFIG_EFI_ZBOOT) += zboot-entry.o zboot.o $(zboot-obj-y)
> >
> > extra-y := $(lib-y)
> > lib-y := $(patsubst %.o,%.stub.o,$(lib-y))
> > diff --git a/drivers/firmware/efi/libstub/Makefile.zboot b/drivers/firmware/efi/libstub/Makefile.zboot
> > index 43e9a4cab9f5..1ed948cee92f 100644
> > --- a/drivers/firmware/efi/libstub/Makefile.zboot
> > +++ b/drivers/firmware/efi/libstub/Makefile.zboot
> > @@ -36,7 +36,7 @@ $(obj)/zboot-header.o: $(srctree)/drivers/firmware/efi/libstub/zboot-header.S FO
> >
> > ZBOOT_DEPS := $(obj)/zboot-header.o $(objtree)/drivers/firmware/efi/libstub/lib.a
> >
> > -LDFLAGS_vmlinuz.efi.elf := -T $(srctree)/drivers/firmware/efi/libstub/zboot.lds
> > +LDFLAGS_vmlinuz.efi.elf := --no-undefined -X -shared -Bsymbolic -z notext --no-apply-dynamic-relocs -T $(srctree)/drivers/firmware/efi/libstub/zboot.lds
> > $(obj)/vmlinuz.efi.elf: $(obj)/vmlinuz.o $(ZBOOT_DEPS) FORCE
> > $(call if_changed,ld)
> >
> > diff --git a/drivers/firmware/efi/libstub/zboot-entry.S b/drivers/firmware/efi/libstub/zboot-entry.S
> > new file mode 100644
> > index 000000000000..072207f2f6ba
> > --- /dev/null
> > +++ b/drivers/firmware/efi/libstub/zboot-entry.S
> > @@ -0,0 +1,35 @@
> > +/* SPDX-License-Identifier: GPL-2.0-only */
> > +
> > +#include <asm/elf.h>
> > +#define ZBOOT_HEADER_BASE 0
> > +
> > + .text
> > +/*
> > + * x0: efi_handle_t
> > + * x1: efi_system_table_t *
> > + */
> > + .global efi_zboot_entry
> > +efi_zboot_entry:
> > + adrp x2, efi_zboot_header
> > + add x2, x2, :lo12:efi_zboot_header
> > + mov x3, ZBOOT_HEADER_BASE
> > + sub x3, x2, x3 // delta between actual and linked address
> > + adrp x4, _rela_start
> > + add x4, x4, :lo12:_rela_start
> > + adrp x5, _rela_end
> > + add x5, x5, :lo12:_rela_end
> > +
> > +0: cmp x5, x4
> > + b.hs 1f
> > + ldp x6, x7, [x4], #24
> > + ldr x8, [x4, #-8]
> > + cmp w7, #R_AARCH64_RELATIVE
> > + b.ne 0b
> > + add x8, x8, x3
> > + str x8, [x6, x3]
> > + b 0b
> > +
> > +1:
> > + dsb ishst
> > + ic iallu
> > + b efi_zboot_main
> > diff --git a/drivers/firmware/efi/libstub/zboot.c b/drivers/firmware/efi/libstub/zboot.c
> > index ba234e062a1a..7aa6b2e6d104 100644
> > --- a/drivers/firmware/efi/libstub/zboot.c
> > +++ b/drivers/firmware/efi/libstub/zboot.c
> > @@ -58,7 +58,7 @@ void __weak efi_cache_sync_image(unsigned long image_base,
> > }
> >
> > asmlinkage efi_status_t __efiapi
> > -efi_zboot_entry(efi_handle_t handle, efi_system_table_t *systab)
> > +efi_zboot_main(efi_handle_t handle, efi_system_table_t *systab)
> > {
> > unsigned long compressed_size = _gzdata_end - _gzdata_start;
> > unsigned long image_base, alloc_size, code_size;
> > diff --git a/drivers/firmware/efi/libstub/zboot.lds b/drivers/firmware/efi/libstub/zboot.lds
> > index 93d33f68333b..631942604c3f 100644
> > --- a/drivers/firmware/efi/libstub/zboot.lds
> > +++ b/drivers/firmware/efi/libstub/zboot.lds
> > @@ -12,6 +12,12 @@ SECTIONS
> > *(.text* .init.text*)
> > }
> >
> > + .rela.dyn : ALIGN(8) {
> > + __efistub__rela_start = .;
> > + *(.rela .rela*)
> > + __efistub__rela_end = .;
> > + }
> > +
> > .rodata : ALIGN(8) {
> > __efistub__gzdata_start = .;
> > *(.gzdata)
> > --
> > 2.31.1
> >
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: [PATCH] efi: zboot: Ensure zboot PIC
2023-03-28 7:32 ` Pingfan Liu
@ 2023-03-28 7:58 ` Ard Biesheuvel
2023-03-28 9:32 ` Pingfan Liu
0 siblings, 1 reply; 7+ messages in thread
From: Ard Biesheuvel @ 2023-03-28 7:58 UTC (permalink / raw)
To: Pingfan Liu
Cc: linux-efi, Kees Cook, Catalin Marinas, Sami Tolvanen, Huacai Chen
On Tue, 28 Mar 2023 at 09:32, Pingfan Liu <kernelfans@gmail.com> wrote:
>
> On Mon, Mar 27, 2023 at 6:57 PM Ard Biesheuvel <ardb@kernel.org> wrote:
> >
> > On Mon, 27 Mar 2023 at 11:51, Pingfan Liu <kernelfans@gmail.com> wrote:
> > >
> > > Using objcopy to reform vmlinuz.efi.elf to vmlinuz.efi will not convey
> > > any relocation information. That means vmlinuz.efi is expected to be
> > > PIC.
> > >
> > > At present, vmlinuz.efi is PIC. But it is better to adopt the same
> >
> > Why is it better?
> >
>
> I think except carefully coded with asm language, there is no
> guarantee which prevents the compiler from generating position
> dependent code. Or is there any presumption here?
>
All object files built under drivers/firmware/efi/libstub are scanned
for absolute relocations, and if any exist, the build is aborted.
> > > solution used by the kernel to resolve the code relocation issue by
> > > itself. That is to resolve R_AARCH64_RELATIVE at the runtime.
> > >
> >
> > This breaks other architectures.
> >
>
> Oops, could it be done by:
> #if defined(_aarch64_)
> #define R_ARCH_RELATIVE R_AARCH64_RELATIVE
> #else
> #define R_ARCH_RELATIVE 0
> #endif
>
> Since any r_type equaling 0 can not be ejected into the relocation
> section, this macro will make the code dummy in essential.
>
So the assembler instructions you are using are also implemented on
RISC-V and LoongArch?
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] efi: zboot: Ensure zboot PIC
2023-03-28 7:58 ` Ard Biesheuvel
@ 2023-03-28 9:32 ` Pingfan Liu
2023-03-28 9:37 ` Ard Biesheuvel
0 siblings, 1 reply; 7+ messages in thread
From: Pingfan Liu @ 2023-03-28 9:32 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: linux-efi, Kees Cook, Catalin Marinas, Sami Tolvanen, Huacai Chen
On Tue, Mar 28, 2023 at 3:58 PM Ard Biesheuvel <ardb@kernel.org> wrote:
>
> On Tue, 28 Mar 2023 at 09:32, Pingfan Liu <kernelfans@gmail.com> wrote:
> >
> > On Mon, Mar 27, 2023 at 6:57 PM Ard Biesheuvel <ardb@kernel.org> wrote:
> > >
> > > On Mon, 27 Mar 2023 at 11:51, Pingfan Liu <kernelfans@gmail.com> wrote:
> > > >
> > > > Using objcopy to reform vmlinuz.efi.elf to vmlinuz.efi will not convey
> > > > any relocation information. That means vmlinuz.efi is expected to be
> > > > PIC.
> > > >
> > > > At present, vmlinuz.efi is PIC. But it is better to adopt the same
> > >
> > > Why is it better?
> > >
> >
> > I think except carefully coded with asm language, there is no
> > guarantee which prevents the compiler from generating position
> > dependent code. Or is there any presumption here?
> >
>
> All object files built under drivers/firmware/efi/libstub are scanned
> for absolute relocations, and if any exist, the build is aborted.
>
Oh, I got the code piece now. Thank you very much for pointing this
out. And only if R_AARCH64_ABS64 is unavoidable, there is no need to
ask the code to fix the relocation by itself.
But one more question, there are many other "S+A" types of relocation,
let's say R_AARCH64_ABS32 or R_AARCH64_LDST64_ABS_LO12_NC. It is also
sensitive to the delta between loading and linking. Should all of them
be excluded by the Makefile?
> > > > solution used by the kernel to resolve the code relocation issue by
> > > > itself. That is to resolve R_AARCH64_RELATIVE at the runtime.
> > > >
> > >
> > > This breaks other architectures.
> > >
> >
> > Oops, could it be done by:
> > #if defined(_aarch64_)
> > #define R_ARCH_RELATIVE R_AARCH64_RELATIVE
> > #else
> > #define R_ARCH_RELATIVE 0
> > #endif
> >
> > Since any r_type equaling 0 can not be ejected into the relocation
> > section, this macro will make the code dummy in essential.
> >
>
> So the assembler instructions you are using are also implemented on
> RISC-V and LoongArch?
Oops. The whole file should be arch dependent. In those cases, they
should be a single jump instruction.
Appreciate for your help.
Thanks,
Pingfan
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: [PATCH] efi: zboot: Ensure zboot PIC
2023-03-28 9:32 ` Pingfan Liu
@ 2023-03-28 9:37 ` Ard Biesheuvel
2023-03-29 8:24 ` Pingfan Liu
0 siblings, 1 reply; 7+ messages in thread
From: Ard Biesheuvel @ 2023-03-28 9:37 UTC (permalink / raw)
To: Pingfan Liu
Cc: linux-efi, Kees Cook, Catalin Marinas, Sami Tolvanen, Huacai Chen
On Tue, 28 Mar 2023 at 11:32, Pingfan Liu <kernelfans@gmail.com> wrote:
>
> On Tue, Mar 28, 2023 at 3:58 PM Ard Biesheuvel <ardb@kernel.org> wrote:
> >
> > On Tue, 28 Mar 2023 at 09:32, Pingfan Liu <kernelfans@gmail.com> wrote:
> > >
> > > On Mon, Mar 27, 2023 at 6:57 PM Ard Biesheuvel <ardb@kernel.org> wrote:
> > > >
> > > > On Mon, 27 Mar 2023 at 11:51, Pingfan Liu <kernelfans@gmail.com> wrote:
> > > > >
> > > > > Using objcopy to reform vmlinuz.efi.elf to vmlinuz.efi will not convey
> > > > > any relocation information. That means vmlinuz.efi is expected to be
> > > > > PIC.
> > > > >
> > > > > At present, vmlinuz.efi is PIC. But it is better to adopt the same
> > > >
> > > > Why is it better?
> > > >
> > >
> > > I think except carefully coded with asm language, there is no
> > > guarantee which prevents the compiler from generating position
> > > dependent code. Or is there any presumption here?
> > >
> >
> > All object files built under drivers/firmware/efi/libstub are scanned
> > for absolute relocations, and if any exist, the build is aborted.
> >
>
> Oh, I got the code piece now. Thank you very much for pointing this
> out. And only if R_AARCH64_ABS64 is unavoidable, there is no need to
> ask the code to fix the relocation by itself.
>
> But one more question, there are many other "S+A" types of relocation,
> let's say R_AARCH64_ABS32 or R_AARCH64_LDST64_ABS_LO12_NC. It is also
> sensitive to the delta between loading and linking. Should all of them
> be excluded by the Makefile?
>
None of those can be used to relocate absolute addresses, so these are
not the ones we should care about.
There are the ones related to the GOT, which could result in GOT
entries in the final executable with R_AARCH64_RELATIVE relocations.
However, we use 'hidden' visibility for all codegen related to the EFI
stub, so the compiler knows all symbol references can be resolved at
link time. This means that under -fpic or -fpie, it will always use
relative references.
> > > > > solution used by the kernel to resolve the code relocation issue by
> > > > > itself. That is to resolve R_AARCH64_RELATIVE at the runtime.
> > > > >
> > > >
> > > > This breaks other architectures.
> > > >
> > >
> > > Oops, could it be done by:
> > > #if defined(_aarch64_)
> > > #define R_ARCH_RELATIVE R_AARCH64_RELATIVE
> > > #else
> > > #define R_ARCH_RELATIVE 0
> > > #endif
> > >
> > > Since any r_type equaling 0 can not be ejected into the relocation
> > > section, this macro will make the code dummy in essential.
> > >
> >
> > So the assembler instructions you are using are also implemented on
> > RISC-V and LoongArch?
>
> Oops. The whole file should be arch dependent. In those cases, they
> should be a single jump instruction.
>
> Appreciate for your help.
>
> Thanks,
>
> Pingfan
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] efi: zboot: Ensure zboot PIC
2023-03-28 9:37 ` Ard Biesheuvel
@ 2023-03-29 8:24 ` Pingfan Liu
0 siblings, 0 replies; 7+ messages in thread
From: Pingfan Liu @ 2023-03-29 8:24 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: linux-efi, Kees Cook, Catalin Marinas, Sami Tolvanen, Huacai Chen
On Tue, Mar 28, 2023 at 5:37 PM Ard Biesheuvel <ardb@kernel.org> wrote:
>
> On Tue, 28 Mar 2023 at 11:32, Pingfan Liu <kernelfans@gmail.com> wrote:
> >
> > On Tue, Mar 28, 2023 at 3:58 PM Ard Biesheuvel <ardb@kernel.org> wrote:
> > >
> > > On Tue, 28 Mar 2023 at 09:32, Pingfan Liu <kernelfans@gmail.com> wrote:
> > > >
> > > > On Mon, Mar 27, 2023 at 6:57 PM Ard Biesheuvel <ardb@kernel.org> wrote:
> > > > >
> > > > > On Mon, 27 Mar 2023 at 11:51, Pingfan Liu <kernelfans@gmail.com> wrote:
> > > > > >
> > > > > > Using objcopy to reform vmlinuz.efi.elf to vmlinuz.efi will not convey
> > > > > > any relocation information. That means vmlinuz.efi is expected to be
> > > > > > PIC.
> > > > > >
> > > > > > At present, vmlinuz.efi is PIC. But it is better to adopt the same
> > > > >
> > > > > Why is it better?
> > > > >
> > > >
> > > > I think except carefully coded with asm language, there is no
> > > > guarantee which prevents the compiler from generating position
> > > > dependent code. Or is there any presumption here?
> > > >
> > >
> > > All object files built under drivers/firmware/efi/libstub are scanned
> > > for absolute relocations, and if any exist, the build is aborted.
> > >
> >
> > Oh, I got the code piece now. Thank you very much for pointing this
> > out. And only if R_AARCH64_ABS64 is unavoidable, there is no need to
> > ask the code to fix the relocation by itself.
> >
> > But one more question, there are many other "S+A" types of relocation,
> > let's say R_AARCH64_ABS32 or R_AARCH64_LDST64_ABS_LO12_NC. It is also
> > sensitive to the delta between loading and linking. Should all of them
> > be excluded by the Makefile?
> >
>
> None of those can be used to relocate absolute addresses, so these are
> not the ones we should care about.
>
> There are the ones related to the GOT, which could result in GOT
> entries in the final executable with R_AARCH64_RELATIVE relocations.
> However, we use 'hidden' visibility for all codegen related to the EFI
> stub, so the compiler knows all symbol references can be resolved at
> link time. This means that under -fpic or -fpie, it will always use
> relative references.
>
Appreciate for the elaboration. I got the whole story now.
Thanks,
Pingfan
>
> > > > > > solution used by the kernel to resolve the code relocation issue by
> > > > > > itself. That is to resolve R_AARCH64_RELATIVE at the runtime.
> > > > > >
> > > > >
> > > > > This breaks other architectures.
> > > > >
> > > >
> > > > Oops, could it be done by:
> > > > #if defined(_aarch64_)
> > > > #define R_ARCH_RELATIVE R_AARCH64_RELATIVE
> > > > #else
> > > > #define R_ARCH_RELATIVE 0
> > > > #endif
> > > >
> > > > Since any r_type equaling 0 can not be ejected into the relocation
> > > > section, this macro will make the code dummy in essential.
> > > >
> > >
> > > So the assembler instructions you are using are also implemented on
> > > RISC-V and LoongArch?
> >
> > Oops. The whole file should be arch dependent. In those cases, they
> > should be a single jump instruction.
> >
> > Appreciate for your help.
> >
> > Thanks,
> >
> > Pingfan
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2023-03-29 8:25 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-03-27 9:51 [PATCH] efi: zboot: Ensure zboot PIC Pingfan Liu
2023-03-27 10:57 ` Ard Biesheuvel
2023-03-28 7:32 ` Pingfan Liu
2023-03-28 7:58 ` Ard Biesheuvel
2023-03-28 9:32 ` Pingfan Liu
2023-03-28 9:37 ` Ard Biesheuvel
2023-03-29 8:24 ` Pingfan Liu
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.