Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <20230621114439.42851-1-alexghiti@rivosinc.com>
 <20230621114439.42851-2-alexghiti@rivosinc.com> <CAHVXubicGLp0-aOpeq7M1Cs3YZ+3WC1d_0gjyaoS8Z1j03JAQQ@mail.gmail.com>
In-Reply-To: <CAHVXubicGLp0-aOpeq7M1Cs3YZ+3WC1d_0gjyaoS8Z1j03JAQQ@mail.gmail.com>
From:   Ard Biesheuvel <ardb@kernel.org>
Date:   Fri, 7 Jul 2023 10:47:32 +0200
Message-ID: <CAMj1kXH1VZqrekHELZG6DdSU6mnF91vo=GbQTYmwJetKB8Cd1Q@mail.gmail.com>
Subject: Re: [RFC PATCH 1/1] libstub: zboot: Use -ffunction-sections + --gc-sections
To:     Alexandre Ghiti <alexghiti@rivosinc.com>
Cc:     linux-kernel@vger.kernel.org, linux-efi@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Fri, 7 Jul 2023 at 10:44, Alexandre Ghiti <alexghiti@rivosinc.com> wrote=
:
>
> Hi Ard,
>
> On Wed, Jun 21, 2023 at 1:45=E2=80=AFPM Alexandre Ghiti <alexghiti@rivosi=
nc.com> 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 sect=
ions
> > (which actually are functions).
> >
> > Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com>
> > ---
> >  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/e=
fi/libstub/Makefile
> > index 3abb2b357482..6182366d00c0 100644
> > --- a/drivers/firmware/efi/libstub/Makefile
> > +++ b/drivers/firmware/efi/libstub/Makefile
> > @@ -40,6 +40,7 @@ KBUILD_CFLAGS                 :=3D $(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/firm=
ware/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/ef=
i/libstub/zboot-header.S FO
> >
> >  ZBOOT_DEPS :=3D $(obj)/zboot-header.o $(objtree)/drivers/firmware/efi/=
libstub/lib.a
> >
> > -LDFLAGS_vmlinuz.efi.elf :=3D -T $(srctree)/drivers/firmware/efi/libstu=
b/zboot.lds
> > +LDFLAGS_vmlinuz.efi.elf :=3D -T $(srctree)/drivers/firmware/efi/libstu=
b/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.