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: <domy5iwmaasksrm7srdmus5vifcxrzvozwpnc3ht43qtxvkjhd@gkyxt3qaeyqu>
Date: Tue, 9 Sep 2025 09:05:40 -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 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.

-- 
Josh