linux-kernel - Re: [PATCH v2 52/62] objtool/klp: Introduce klp diff subcommand for diffing object files

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: <6bzrbh6sotmdh2426iky6s74yqfwiiooe5k3wif72pdvrpi322@23gntwfq7n7z>
Date: Tue, 10 Jun 2025 13:26:03 -0700
From: Josh Poimboeuf <jpoimboe@...nel.org>
To: Joe Lawrence <joe.lawrence@...hat.com>
Cc: x86@...nel.org, linux-kernel@...r.kernel.org, 
	Petr Mladek <pmladek@...e.com>, Miroslav Benes <mbenes@...e.cz>, live-patching@...r.kernel.org, 
	Song Liu <song@...nel.org>, laokz <laokz@...mail.com>, Jiri Kosina <jikos@...nel.org>, 
	Marcos Paulo de Souza <mpdesouza@...e.com>, Weinan Liu <wnliu@...gle.com>, 
	Fazla Mehrab <a.mehrab@...edance.com>, Chen Zhongjin <chenzhongjin@...wei.com>, 
	Puranjay Mohan <puranjay@...nel.org>
Subject: Re: [PATCH v2 52/62] objtool/klp: Introduce klp diff subcommand for
 diffing object files

On Tue, Jun 10, 2025 at 08:39:10AM -0400, Joe Lawrence wrote:
> >> Should we check for other data section prefixes here, like:
> >>
> >> 			else {
> >> 				snprintf(sec_name, SEC_NAME_LEN, ".rodata.%s", sym->name);
> >> 				if (!strcmp(sym->sec->name, sec_name))
> >> 					found_data = true;
> >> 			}
> > 
> > Indeed.  And also .bss.*.
> > 
> >> At the same time, while we're here, what about other .text.* section
> >> prefixes?
> > 
> > AFAIK, .text.* is the only one.
> > 
> 
> What about .text.unlikely, .text.hot (not sure if these can come alone
> or are only optimization copies) ?

Hm, I think .text.unlikely.foo is at least theoretically possible
without .text.foo.  Seems "unlikely" though.

IIRC, .text.hot is used for profile-guided optimization, probably not a
concern here.

There are actually several edge cases that would cause this validation
to fail.  If a module only had init/exit then it wouldn't have any
.text.foo.  Or if it didn't have global data then there'd be no
.[ro]data.foo.

This function could get pretty fiddly, and honestly I'm not sure this
validation buys us much anyway.  I'm thinking about just removing it
altogether...

-- 
Josh