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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <CAAhV-H47VKERJCKRi7uAS7OmCWaE4yxZ07Hwz_si2DMVRDrsag@mail.gmail.com>
Date: Thu, 4 Sep 2025 11:59:30 +0800
From: Huacai Chen <chenhuacai@...nel.org>
To: Tiezhu Yang <yangtiezhu@...ngson.cn>
Cc: Josh Poimboeuf <jpoimboe@...nel.org>, 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 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".

Huacai

>
> Thanks,
> Tiezhu
>