Static linking is done at an object file (actually section) granularity,
meaning that if a function in an object has an undefined reference, the
link will fail, even though this function is not used in the resulting
ELF.
To avoid such failures, allow the linker to garbage collect unused sections
(which actually are functions).
Signed-off-by: Alexandre Ghiti <[email protected]>
---
drivers/firmware/efi/libstub/Makefile | 1 +
drivers/firmware/efi/libstub/Makefile.zboot | 2 +-
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/firmware/efi/libstub/Makefile b/drivers/firmware/efi/libstub/Makefile
index 3abb2b357482..6182366d00c0 100644
--- a/drivers/firmware/efi/libstub/Makefile
+++ b/drivers/firmware/efi/libstub/Makefile
@@ -40,6 +40,7 @@ KBUILD_CFLAGS := $(subst $(CC_FLAGS_FTRACE),,$(cflags-y)) \
-ffreestanding \
-fno-stack-protector \
$(call cc-option,-fno-addrsig) \
+ -ffunction-sections \
-D__DISABLE_EXPORTS
#
diff --git a/drivers/firmware/efi/libstub/Makefile.zboot b/drivers/firmware/efi/libstub/Makefile.zboot
index 89ef820f3b34..5bb52d262133 100644
--- a/drivers/firmware/efi/libstub/Makefile.zboot
+++ b/drivers/firmware/efi/libstub/Makefile.zboot
@@ -51,7 +51,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 := -T $(srctree)/drivers/firmware/efi/libstub/zboot.lds --gc-sections
$(obj)/vmlinuz.efi.elf: $(obj)/vmlinuz.o $(ZBOOT_DEPS) FORCE
$(call if_changed,ld)
--
2.39.2
On Fri, 7 Jul 2023 at 10:44, Alexandre Ghiti <[email protected]> wrote:
>
> Hi Ard,
>
> On Wed, Jun 21, 2023 at 1:45 PM Alexandre Ghiti <[email protected]> wrote:
> >
> > Static linking is done at an object file (actually section) granularity,
> > meaning that if a function in an object has an undefined reference, the
> > link will fail, even though this function is not used in the resulting
> > ELF.
> >
> > To avoid such failures, allow the linker to garbage collect unused sections
> > (which actually are functions).
> >
> > Signed-off-by: Alexandre Ghiti <[email protected]>
> > ---
> > drivers/firmware/efi/libstub/Makefile | 1 +
> > drivers/firmware/efi/libstub/Makefile.zboot | 2 +-
> > 2 files changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/firmware/efi/libstub/Makefile b/drivers/firmware/efi/libstub/Makefile
> > index 3abb2b357482..6182366d00c0 100644
> > --- a/drivers/firmware/efi/libstub/Makefile
> > +++ b/drivers/firmware/efi/libstub/Makefile
> > @@ -40,6 +40,7 @@ KBUILD_CFLAGS := $(subst $(CC_FLAGS_FTRACE),,$(cflags-y)) \
> > -ffreestanding \
> > -fno-stack-protector \
> > $(call cc-option,-fno-addrsig) \
> > + -ffunction-sections \
> > -D__DISABLE_EXPORTS
> >
> > #
> > diff --git a/drivers/firmware/efi/libstub/Makefile.zboot b/drivers/firmware/efi/libstub/Makefile.zboot
> > index 89ef820f3b34..5bb52d262133 100644
> > --- a/drivers/firmware/efi/libstub/Makefile.zboot
> > +++ b/drivers/firmware/efi/libstub/Makefile.zboot
> > @@ -51,7 +51,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 := -T $(srctree)/drivers/firmware/efi/libstub/zboot.lds --gc-sections
> > $(obj)/vmlinuz.efi.elf: $(obj)/vmlinuz.o $(ZBOOT_DEPS) FORCE
> > $(call if_changed,ld)
> >
> > --
> > 2.39.2
> >
>
> Sorry to bother you, do you have any opinion about this patch? Does
> that make sense? If not, I should find another solution for my riscv
> KASLR series!
>
Hi,
Apologies for the delay in responding. I have been away and email
tends to pile up a bit.
The patch by itself looks fine to me, but I do wonder if your series
could be improved slightly by moving those newly shared pieces into a
separate source file, rather than to an existing one.
Hi Ard,
On Wed, Jun 21, 2023 at 1:45 PM Alexandre Ghiti <[email protected]> wrote:
>
> Static linking is done at an object file (actually section) granularity,
> meaning that if a function in an object has an undefined reference, the
> link will fail, even though this function is not used in the resulting
> ELF.
>
> To avoid such failures, allow the linker to garbage collect unused sections
> (which actually are functions).
>
> Signed-off-by: Alexandre Ghiti <[email protected]>
> ---
> drivers/firmware/efi/libstub/Makefile | 1 +
> drivers/firmware/efi/libstub/Makefile.zboot | 2 +-
> 2 files changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/firmware/efi/libstub/Makefile b/drivers/firmware/efi/libstub/Makefile
> index 3abb2b357482..6182366d00c0 100644
> --- a/drivers/firmware/efi/libstub/Makefile
> +++ b/drivers/firmware/efi/libstub/Makefile
> @@ -40,6 +40,7 @@ KBUILD_CFLAGS := $(subst $(CC_FLAGS_FTRACE),,$(cflags-y)) \
> -ffreestanding \
> -fno-stack-protector \
> $(call cc-option,-fno-addrsig) \
> + -ffunction-sections \
> -D__DISABLE_EXPORTS
>
> #
> diff --git a/drivers/firmware/efi/libstub/Makefile.zboot b/drivers/firmware/efi/libstub/Makefile.zboot
> index 89ef820f3b34..5bb52d262133 100644
> --- a/drivers/firmware/efi/libstub/Makefile.zboot
> +++ b/drivers/firmware/efi/libstub/Makefile.zboot
> @@ -51,7 +51,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 := -T $(srctree)/drivers/firmware/efi/libstub/zboot.lds --gc-sections
> $(obj)/vmlinuz.efi.elf: $(obj)/vmlinuz.o $(ZBOOT_DEPS) FORCE
> $(call if_changed,ld)
>
> --
> 2.39.2
>
Sorry to bother you, do you have any opinion about this patch? Does
that make sense? If not, I should find another solution for my riscv
KASLR series!
Thanks,
Alex
On Fri, Jul 7, 2023 at 10:47 AM Ard Biesheuvel <[email protected]> wrote:
>
> On Fri, 7 Jul 2023 at 10:44, Alexandre Ghiti <[email protected]> wrote:
> >
> > Hi Ard,
> >
> > On Wed, Jun 21, 2023 at 1:45 PM Alexandre Ghiti <[email protected]> wrote:
> > >
> > > Static linking is done at an object file (actually section) granularity,
> > > meaning that if a function in an object has an undefined reference, the
> > > link will fail, even though this function is not used in the resulting
> > > ELF.
> > >
> > > To avoid such failures, allow the linker to garbage collect unused sections
> > > (which actually are functions).
> > >
> > > Signed-off-by: Alexandre Ghiti <[email protected]>
> > > ---
> > > drivers/firmware/efi/libstub/Makefile | 1 +
> > > drivers/firmware/efi/libstub/Makefile.zboot | 2 +-
> > > 2 files changed, 2 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/firmware/efi/libstub/Makefile b/drivers/firmware/efi/libstub/Makefile
> > > index 3abb2b357482..6182366d00c0 100644
> > > --- a/drivers/firmware/efi/libstub/Makefile
> > > +++ b/drivers/firmware/efi/libstub/Makefile
> > > @@ -40,6 +40,7 @@ KBUILD_CFLAGS := $(subst $(CC_FLAGS_FTRACE),,$(cflags-y)) \
> > > -ffreestanding \
> > > -fno-stack-protector \
> > > $(call cc-option,-fno-addrsig) \
> > > + -ffunction-sections \
> > > -D__DISABLE_EXPORTS
> > >
> > > #
> > > diff --git a/drivers/firmware/efi/libstub/Makefile.zboot b/drivers/firmware/efi/libstub/Makefile.zboot
> > > index 89ef820f3b34..5bb52d262133 100644
> > > --- a/drivers/firmware/efi/libstub/Makefile.zboot
> > > +++ b/drivers/firmware/efi/libstub/Makefile.zboot
> > > @@ -51,7 +51,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 := -T $(srctree)/drivers/firmware/efi/libstub/zboot.lds --gc-sections
> > > $(obj)/vmlinuz.efi.elf: $(obj)/vmlinuz.o $(ZBOOT_DEPS) FORCE
> > > $(call if_changed,ld)
> > >
> > > --
> > > 2.39.2
> > >
> >
> > Sorry to bother you, do you have any opinion about this patch? Does
> > that make sense? If not, I should find another solution for my riscv
> > KASLR series!
> >
>
> Hi,
>
> Apologies for the delay in responding. I have been away and email
> tends to pile up a bit.
No worries!
>
> The patch by itself looks fine to me, but I do wonder if your series
> could be improved slightly by moving those newly shared pieces into a
> separate source file, rather than to an existing one.
If you prefer this solution, I'll do that then.
But I'm happy the patch makes sense to you, I'll probably use this to
fix some issues/limitations with the riscv pre-mmu code :)
Thanks for your quick answer!
Alex