linux-kernel - Re: kallsyms __print_symbol prints first weak symbol encountered

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: <47278AB5.5060308@grupopie.com>
Date:	Tue, 30 Oct 2007 19:49:09 +0000
From:	Paulo Marques <pmarques@...popie.com>
To:	Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>
CC:	Rusty Russell <rusty@...tcorp.com.au>,
	linux-kernel@...r.kernel.org,
	"systemtap@...rceware.org" <systemtap@...rceware.org>
Subject: Re: kallsyms __print_symbol prints first weak symbol encountered

Mathieu Desnoyers wrote:
> Hi,

Hi,

> [...]
> kallsyms returns the first symbol encountered, even though it is weak,
> when it should in fact return sys_ni_syscall.
> 
> Is it a concern for anyone else out there ? Would it make sense to fix
> it ?

I don't know if it is a concern, but if we're going to fix it, we should
probably do it in "scripts/kallsyms" by providing a list that is already
sorted according to "address, weakness".

This way the run-time kernel keeps the current behavior, without any 
overhead. Something along the lines of the attached patch (just compile 
tested).

However, this is an area where we've had problems in the past with some 
architectures giving different results between passes, and then any 
change to the symbol order might make the problem worse and make the 
build process fail with a "Inconsistent kallsyms data" error message.

So, if someone wants to use this, it should go through -mm for a while, 
first.

-- 
Paulo Marques - www.grupopie.com

"All I ask is a chance to prove that money can't make me happy."

View attachment "patch" of type "text/plain" (1468 bytes)