linux-kernel - Re: [PATCH v4 00/28] objtool: Function validation tracing

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: <yuqfimcwfjc7l4pitq5a2t4ygb2fexhaveivpqw5ub5my6b2jz@ehhtv44bfiut>
Date: Mon, 17 Nov 2025 14:38:49 -0800
From: Josh Poimboeuf <jpoimboe@...nel.org>
To: David Laight <david.laight.linux@...il.com>
Cc: Alexandre Chartre <alexandre.chartre@...cle.com>, 
	linux-kernel@...r.kernel.org, mingo@...nel.org, peterz@...radead.org
Subject: Re: [PATCH v4 00/28] objtool: Function validation tracing

On Mon, Nov 17, 2025 at 10:09:53PM +0000, David Laight wrote:
> On Mon, 17 Nov 2025 14:11:55 +0100
> Alexandre Chartre <alexandre.chartre@...cle.com> wrote:
> 
> > On 11/17/25 13:37, David Laight wrote:
> > > On Mon, 17 Nov 2025 10:47:06 +0100
> > > Alexandre Chartre <alexandre.chartre@...cle.com> wrote:
> > >   
> > >> On 11/17/25 10:42, David Laight wrote:  
> > > ...  
> > >>> Although I think there ought to be some indication of the 31 NOP bytes
> > >>> at the end of the middle alternative.  

I'm not sure we need that.  It's already implied those gaps will be
filled with NOPs.  This could add unnecessary visual clutter.

> > >>
> > >> I am now compacting the code by removing all trailing NOPs. I should probably
> > >> improve that with printing the actual number of NOPs, for example NOP31 (or nop31)  
> > > 
> > > That is the sort of thing I was thinking of.
> > > Perhaps the actual opcodes on one line - eg: NOP5; NOP5; NOP5; NOP1  
> > 
> > That might not always be very compact. For example __switch_to_asm() has 41 NOP1.
> > I will use NOP<n> for now, and we can improve later.
> 
> Could you use NOP1*41 (etc) so that NOP5*4 is different from NOP1*20?
> (I'm guessing you hand-decode the standard NOP sequences already?)
> 
> Hmm... you don't want to execute that many 0x90 bytes.
> I think that case might have had a jump around them.
> 
> Do I remember something about the trailing nop being merged?
> Perhaps that is the kernel patching code.
> Something made me think objtool might (also) be doing it.

Yes, IIRC, the alternatives code merges the small NOPs into bigger ones.

-- 
Josh