linux-kernel - Re: odd objtool 'unreachable instruction' warning

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: <CAHk-=wgs8+xVbv5tu9kv5n=LwWFZ0FW4GPwVmXBPjLQ0goLfjQ@mail.gmail.com>
Date: Tue, 28 Oct 2025 17:59:01 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Josh Poimboeuf <jpoimboe@...nel.org>
Cc: Peter Zijlstra <peterz@...radead.org>, 
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>, 
	Alexandre Chartre <alexandre.chartre@...cle.com>
Subject: Re: odd objtool 'unreachable instruction' warning

On Tue, 28 Oct 2025 at 17:21, Josh Poimboeuf <jpoimboe@...nel.org> wrote:
>
> See the diff below, hopefully that fixes things for you?

Bingo, that patch works for me.

> On a related note, it would be nice if we could make that codegen more
> readable...  Here were a few formats I had played with before, any
> thoughts?

I don't think any of this is ever going to be remotely readable,
because of the whole horrible section noise.

If I recall correctly, one of the ideas you had was to use macros to
make things more legible, but that sadly didn't work with clang or
something like that?

Anyway, I certainly agree that we can make it *slightly* better, and
I'm not objecting to trying to do some incremental improvement, but
it's just always going to be pretty bad, and so I'd probably always
end up doing my ugly hack anyway.

Because for the assembler readability case, I do think the "avoid
alternatives" is just fundamentally nicer and simpler.

Now, at one point I tried to do a build config option to just have the
"assume feature XYZ" - so that you could just have a config option
that turns on SMAP and other features unconditionally.

That made the asm obviously look fine, but my simplistic patch at the
time made the source code itself so much less legible that I trashed
it. It just ended up being a mess of ifdefs.

(I did think that maybe I could make my patch cleaner with a few
helper macros, but it all ended up feeling like I was overthinking
things.  I suspect very few people actually care about that legible
assembler thing. End result: I just ended up with the very simple
local hack in my tree)

> Note there's also an objtool "disas" feature Alexandre is working on
> which will show the disassembly annotated with runtime patching info
> (alternatives, static branches, etc):

Yeah, that would be a good feature to have, although I wouldn't
obviate the asm cleanup for me.

Depending on what I am looking for, I end up looking at either the asm
output and the objdump output (or at both) because they each have
their good and bad parts.

Sometimes I *want* the comments that gcc in particular adds to the
assembler, and sometimes I prefer the "raw objdump" format.

Oh, and Alexandre: if you are working on improving objdump - are you
perhaps also looking at making the relocation output saner?

Because I absolutely detest the odd relocation output format. I use it
occasionally, but it's just crazy to see things like

<delayed_put_task_struct>:
        ...
        call   <delayed_put_task_struct+0x1a>
                        R_X86_64_PLT32  rethook_flush_task-0x4

when any *sane* tool would just output the simple

        call   rethook_flush_task

instead.  Because as it is, the line without the relocation info is
useless, and then the separate relocation line (with -r) is just
crazy.

I kind of do understand why it happens - few people care, objdump
supports many different instruction formats, the instruction decoding
is a separate thing from the relocation logic etc etc. But if somebody
is looking at making objdump generate prettier output, I'd love for
this to be one of the things fixed.

(And yes, I see this horrid output because I run objdump on individual
object files before linking, because it's *so* much simpler and
quicker)

Again - the real problem is that I'm just doing odd things that are
probably unusual enough that very few people care. And I've done it so
long that I can deal with it and read the horrors when necessary.

So it's not like this is a huge problem, it's just that I go "Oh Gods,
objdump output is not meant for humans" every time I do this.

                Linus