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: <kuf6r3fuxftpwccnz7llw6vta4ec5f2z53isgw34iow546j73l@zbcse36q6dsj>
Date: Wed, 10 Sep 2025 20:23: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 Wed, Sep 10, 2025 at 02:55:20PM +0800, Huacai Chen wrote:
> 
> 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:
> >
> > 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.

There's no need for anything special... Fo ARM64 and RISC-V, if their
head "code" is actually just structured data, that *also* belongs in a
data section.

And that can get changed if/when they get objtool support.  If not
before.

> 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.

Hm?  Objtool can handle "non-regular" functions fine.  That's what the
unwind hints are for.  x86 has that already and it works fine.

What *actually* causes problems for objtool (and the whole point of this
discussion) is the placing of data in a text section.  I don't
understand why we're still arguing about whether that's the right thing
to do.  Not to mention the fact that using objtool as an excuse *not* to
do it seems completely backwards!

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

Unwinding can easily (and often does) happen during boot, before init
memory is freed.

It could even happen in the head code, e.g. in a debugger.  (whether
that actually works might be a different story.)

But also, keep in mind that objtool has many other features beyond just
ORC generation.  In the future it would be quite foreseeable for some
other objtool feature to get confused by this "code" again and spit out
more warnings.

Similarly, if loongarch eventually switches to using sframe, and the
binutils assembler learns how to autogenerate sframe with minimal cfi
directives (a planned feature I believe), it would have the same problem
trying to decipher this "code".

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

I'm not convinced of that.  I don't think we want to ignore it on x86.

-- 
Josh