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] [day] [month] [year] [list]

Message-ID: <CAAhV-H47Tfzb-JbM1-mN1c0WaodPM0G0ip6NCDwZb8Yj=E8+Fw@mail.gmail.com>
Date: Wed, 10 Sep 2025 14:55:20 +0800
From: Huacai Chen <chenhuacai@...nel.org>
To: Josh Poimboeuf <jpoimboe@...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

Hi, Josh,

On Wed, Sep 10, 2025 at 12:05 AM Josh Poimboeuf <jpoimboe@...nel.org> wrote:
>
> On Tue, Sep 09, 2025 at 12:10:29PM +0800, Huacai Chen wrote:
> > On Tue, Sep 9, 2025 at 12:00 PM Tiezhu Yang <yangtiezhu@...ngson.cn> wrote:
> > >
> > > On 2025/9/6 上午12:04, Josh Poimboeuf wrote:
> > > > On Fri, Sep 05, 2025 at 12:36:16PM +0800, Huacai Chen wrote:
> > > >> Hi, Josh,
> > > >>
> > > >> On Fri, Sep 5, 2025 at 5:46 AM Josh Poimboeuf <jpoimboe@...nel.org> wrote:
> > > >>>
> > > >>> On Thu, Sep 04, 2025 at 10:39:30AM -0700, Josh Poimboeuf wrote:
> > > >>>> On Thu, Sep 04, 2025 at 11:59:30AM +0800, Huacai Chen wrote:
> > > >>>>> 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.
> > > >>>
> > > >>> Actually, the "x" attribute isn't needed for vmlinux.  The vmlinux
> > > >>> linker script places it in the text region regardless.
> > > >>>
> > > >>> Moving the data to a data section should be really simple, something
> > > >>> like the below.
> > > >>>
> > > >>> And yes, even the above RISC-V code can be in a data section.  Those
> > > >>> instructions are part of the 'struct riscv_image_header' data structure.
> > > >> This may work but also look strange (code in data section), it is more
> > > >> like a "workaround". :)
> > > >
> > > > The "strange" part of the code is the intermixing of code and data.  If
> > > > they can't be separated, then they are part of a data structure and
> > > > belong in a data section.
> > >
> > > I tried the following minimal changes, put the image header into
> > > the section .head.data, do not link efistub lib.a into vmlinux.o,
> > > just link efistub lib.a into vmlinux, no other changes, they have
> > > same effect with patch #1 and #2, what do you think?
> > I still don't think we have to put the HEAD into a data section. Yes,
> > it is a mix of code and data, but the data is read-only so it doesn't
> > need the "w" attribute (and code needs "x", at least in theory).
>
> Then it can be __HEAD_RODATA, with the "w" removed:
>
> #define __HEAD_RODATA   .section        ".head.rodata","a"
>
> > From my point of view, the text section is still the best for HEAD.
>
> It belongs in a data section for two reasons:
>
>   1) It's an image header data structure.
>
>   2) We don't want objtool (or any other tooling) to try to validate it
>      or otherwise treat it as text during the build.
I'm sorry but I insist on my opinion. :)

Yes, there are reasons to put it into a data section, but there are
also reasons to put it into a code section.

1) ARM64, RISC-V and LoongArch have the same style (mix code and data
in __HEAD), I don't want to do something special.

2) __HEAD is used for nearly all archs, except ARM64, RISC-V and
LoongArch, other archs are almost pure code (so they must use a code
section). However, the code in __HEAD is usually not like a regular
function. In other word, if other archs add objtool support, __HEAD
will also probably cause problems.

3) Many archs put __HEAD between __init_begin and __init_end, which
means it is discarded at runtime, stack unwinder is useless for it.

So, ignoring .head.text is not just a workaround for LoongArch, it is
a proper solution for other archs.


Huacai

>
> --
> Josh
>