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: <20251029130057.70a8f487@pumpkin>
Date: Wed, 29 Oct 2025 13:00:57 +0000
From: David Laight <david.laight.linux@...il.com>
To: Peter Zijlstra <peterz@...radead.org>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>, Josh Poimboeuf
 <jpoimboe@...nel.org>, Linux Kernel Mailing List
 <linux-kernel@...r.kernel.org>
Subject: Re: odd objtool 'unreachable instruction' warning

On Wed, 29 Oct 2025 11:05:33 +0100
Peter Zijlstra <peterz@...radead.org> wrote:

> On Wed, Oct 29, 2025 at 09:56:38AM +0000, David Laight wrote:
> > On Tue, 28 Oct 2025 12:29:11 -0700
> > Linus Torvalds <torvalds@...ux-foundation.org> wrote:
> >   
> > > Josh, Peter,
> > >  due to another entirely unrelated discussion, I ended up resurrecting
> > > my "make asm readable" patch that I have had in my local tree when I
> > > want to look at the actual generated code for user accesses.
> > > 
> > > That is a local hack that just removes the alternative noise for the
> > > common ops, so that I actually see the fences and clac/stac
> > > instructions as such, instead of seeing them as nops in the object
> > > file or as horrible noise in the assembler output.  
> > 
> > I've toyed with using explicit nop sequences that would be identifiable
> > as stac, clac and lfence.
> > 
> > At least that would tell you which is which.
> > 
> > Since the flags can be trashed there are plenty to choose from.
> > (eg all the cmpb $n,%reg if you don't mind a false dependency.)  
> 
> As long as you ensure that insn_is_nop() recognises it as such, they
> won't actually ever get ran after alternative patching, since they'll be
> rewritten in canonical nops by optimize_nops().

Ah - I've wondered about the 'nop; nop; nop' being slightly sub-optimal.
But it is hard enough to see what happens to the alternative that is
selected never mind the ones that aren't.

Instructions that change the flags can't be changed to nops.
So possibly the best options are the 0f-1f-cx (for x 0..7).
So 'long_nop %reg' rather than 0f-1f-00 'long_nop [%rax]'.

(But I've not checked the full rules for the addressing modes of
'long_nop'.)

	David