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: <72juhabxma7rw5eq2gglct4lmeoqfvrlv5jf36sdcfimz5rxxd@gnfuxdgv6stj>
Date: Wed, 3 Dec 2025 09:46:53 -0800
From: Josh Poimboeuf <jpoimboe@...nel.org>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Ingo Molnar <mingo@...nel.org>, linux-kernel@...r.kernel.org, 
	linux-tip-commits@...r.kernel.org, x86@...nel.org
Subject: Re: [tip: objtool/urgent] objtool: Consolidate annotation macros

On Wed, Dec 03, 2025 at 09:21:55AM -0800, Linus Torvalds wrote:
> On Wed, 3 Dec 2025 at 08:57, Ingo Molnar <mingo@...nel.org> wrote:
> >
> > Find below a diff of the arch/x86/kernel/process.s output
> > of your tree versus current tip:objtool/urgent.
> 
> Yeah, just a single example would have been sufficient, ie a simple
> 
>    Turn
> 
>         911:
>                .pushsection .discard.annotate_insn,"M", @progbits, 8
>                .long 911b - .
>                .long 1
>                .popsection
>                jmp __x86_return_thunk
> 
>   Into
> 
>         911: .pushsection ".discard.annotate_insn", "M", @progbits, 8;
> .long 911b - .; .long 1; .popsection
>         jmp __x86_return_thunk
> 
> and btw, the quotes around the section name are not necessary afaik.

Indeed, I can remove those quotes.

> Also, I have to say that being mergeable is a bit annoying here:
> without that, we could drop the "@progbits, 8" parts too which is just
> strange noise.  Is the mergeability really a win? Because I'd assume
> that it's never *actually* merged, since the expression "911b-." ends
> up being a unique value?
> 
> What am I missing? It *feels* like this should just all be
> 
>         911: .pushsection .discard.annotate_insn ; .long 911b - .;
> .long 1; .popsection
>         jmp __x86_return_thunk
> 
> instead. But it's entirely possible I'm not seeing the reason here...

So that mergeable thing is the only way to convince the toolchains to
allow setting the section entsize, which is a generic way for objtool to
look at the myriad of special sections and determine their entry sizes,
so it can extract individual entries for the purposes of creating
livepatch modules.

In this case I do realize the irony of objtool needing to know the
section size of a section which is explicitly created for objtool's use
(so of course it already knows the size).

In actuality they are two completely separate subcommands of objtool.
"Regular" objtool reads .discard.annotate_insn for its annotations,
whereas "objtool klp diff" extracts special section entries.  It does so
in a generic way (entsize), regardless of whether the special section is
objtool-specific or not (e.g., the bug table).

-- 
Josh

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ