linux-kernel - Re: [PATCH v1 2/3] objtool/LoongArch: Fix unreachable instruction warnings about EFISTUB

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <ybv2ndrzbqztkctzwhfphpdqrqbxlougs75glm22rcuzdmnrfp@lqwcms3j2d55>
Date: Thu, 4 Sep 2025 10:39:30 -0700
From: Josh Poimboeuf <jpoimboe@...nel.org>
To: Huacai Chen <chenhuacai@...nel.org>
Cc: Tiezhu Yang <yangtiezhu@...ngson.cn>, 
	Peter Zijlstra <peterz@...radead.org>, Nathan Chancellor <nathan@...nel.org>, loongarch@...ts.linux.dev, 
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v1 2/3] objtool/LoongArch: Fix unreachable instruction
 warnings about EFISTUB

On Thu, Sep 04, 2025 at 11:59:30AM +0800, Huacai Chen wrote:
> On Thu, Sep 4, 2025 at 11:50 AM Tiezhu Yang <yangtiezhu@...ngson.cn> wrote:
> >
> > On 2025/9/4 上午10:21, Huacai Chen wrote:
> > > On Thu, Sep 4, 2025 at 10:18 AM Tiezhu Yang <yangtiezhu@...ngson.cn> wrote:
> > >>
> > >> On 2025/9/4 上午3:19, Josh Poimboeuf wrote:
> > >>> On Mon, Sep 01, 2025 at 04:39:29PM +0800, Tiezhu Yang wrote:
> > >>>> On 2025/9/1 下午4:19, Peter Zijlstra wrote:
> > >>>>> On Mon, Sep 01, 2025 at 03:21:55PM +0800, Tiezhu Yang wrote:
> > >>>>>> When compiling with LLVM and CONFIG_LTO_CLANG is set, there exist the
> > >>>>>> following objtool warnings:
> > >>
> > >> ...
> > >>
> > >>>> Josh suggested to do something to put these instructions in the data
> > >>>> section, but as said in the previous reply, it needs to modify the link
> > >>>> process and seems too complicated and expensive for this warning to some
> > >>>> extent.
> > >>>>
> > >>>> So I did this change for objtool.
> > >>>
> > >>> I don't like this workaround either, how exactly is it complicated and
> > >>> expensive to put the data in a data section?
> > >>
> > >> I can put them in a data section in the next version, this is
> > >> reasonable.
> > > No, from the ARM64 and RISC-V design, we can put jump instructions in
> > > the HEAD section, and this is what Jiaxun wants to do. Changing to a
> > > data section is not reasonable.
> >
> > ARM64, RISC-V and LoongArch share the same logic in efistub:
> >
> > $ grep -r "libstub/lib.a" arch/*/Makefile
> > arch/arm64/Makefile:libs-$(CONFIG_EFI_STUB) +=
> > $(objtree)/drivers/firmware/efi/libstub/lib.a
> > arch/loongarch/Makefile:libs-$(CONFIG_EFI_STUB) +=
> > $(objtree)/drivers/firmware/efi/libstub/lib.a
> > arch/riscv/Makefile:libs-$(CONFIG_EFI_STUB) +=
> > $(objtree)/drivers/firmware/efi/libstub/lib.a
> >
> > If we can not put the these data to a data section, then we can not
> > link efistub separately, because if remove the following code in
> > arch/loongarch/Makefile:
> >
> > libs-$(CONFIG_EFI_STUB) += $(objtree)/drivers/firmware/efi/libstub/lib.a
> >
> > there exists the following build error:
> >
> >     LD      vmlinux.o
> >    OBJCOPY modules.builtin.modinfo
> >    GEN     modules.builtin
> >    GEN     .vmlinux.objs
> >    MODPOST Module.symvers
> >    UPD     include/generated/utsversion.h
> >    CC      init/version-timestamp.o
> >    KSYMS   .tmp_vmlinux0.kallsyms.S
> >    AS      .tmp_vmlinux0.kallsyms.o
> >    LD      .tmp_vmlinux1
> > ld: arch/loongarch/kernel/head.o: in function `pe_header':
> > (.head.text+0x68): undefined reference to `__efistub_efi_pe_entry'
> >
> > What should to do in the next step? I am looking forward to your
> > final conclusion.
> 
> This is from RISC-V code.
> 
> __HEAD
> SYM_CODE_START(_start)
>         /*
>          * Image header expected by Linux boot-loaders. The image header data
>          * structure is described in asm/image.h.
>          * Do not modify it without modifying the structure and all bootloaders
>          * that expects this header format!!
>          */
> #ifdef CONFIG_EFI
>         /*
>          * This instruction decodes to "MZ" ASCII required by UEFI.
>          */
>         c.li s4,-13
>         j _start_kernel
> #else
>         /* jump to start kernel */
>         j _start_kernel
>         /* reserved */
>         .word 0
> #endif
> 
> The HEAD section has instructions, if you change it into a data
> section then it loses the "x" attribute.
> 
> So my conclusion is this series is the correct solution for all
> non-x86 archs. We don't need to treat it as "workarounds".

Ok.  In that case please put the full justifications for these changes
in the patch descriptions.

-- 
Josh