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: <52056c29-4f21-83c9-db1f-ebd1875a3675@loongson.cn>
Date: Thu, 4 Sep 2025 11:50:32 +0800
From: Tiezhu Yang <yangtiezhu@...ngson.cn>
To: Huacai Chen <chenhuacai@...nel.org>
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 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.

Thanks,
Tiezhu