linux-kernel - Re: /proc/kallsyms broken in 2.6.26-rc1-git6

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 12 May 2008 10:55:27 +0100
From:	Paulo Marques <pmarques@...popie.com>
To:	Andi Kleen <andi@...stfloor.org>
CC:	linux-kernel@...r.kernel.org
Subject: Re: /proc/kallsyms broken in 2.6.26-rc1-git6

Andi Kleen wrote:
>> That's not for me to judge, but I believe it has always been like that.
> 
> No, normally /proc/kallsyms looks similar to System.tap. Where are all
> these DW.* symbols coming from? 

Hum... System.map is generated by running

nm -n vmlinux | grep -v '\( [aUw] \)\|\(__crc_\)\|\( \$[adt]\)' > System.map

whereas the kallsyms symbols come from:

nm -n vmlinux

So, the only difference is the filter made by that "grep -v" to exclude 
a few classes of symbols.

Maybe I lost myself in that expression, but it doesn't seem like it 
would be able to filter out the symbols you're seeing. Are you sure the 
same symbols don't appear in System.map?

> They didn't use to be there and don't
> make any sense because they don't have any valid kernel addresses.

I don't know enough about the markers infrastructure but I guess these 
"addresses" are more like an "offset" into a markers structure that is 
automatically produced by putting these symbols into a special section 
that starts at offset 0.

>> I just wanted to understand if you noticed a change in behavior (which
>> is probably a bug) or if it has always been like that but you just
>> noticed how ugly it is.
> 
> I noticed a change in behavior.

Ok.

>> Maybe you also have some debug or markers configuration or something
>> that is generating extra symbols to a special section that is just
>> making the problem look worse now.
> 
> Nothing particular. I uploaded the config at
> http://halobates.de/basil-config

Well, my first suspects would be these:

CONFIG_KPROBES=y
CONFIG_KRETPROBES=y
CONFIG_HAVE_KPROBES=y
CONFIG_HAVE_KRETPROBES=y

>> Anyway, I can change the way kallsyms works, but that has to be done
>> with some care because there are some userspace tools that read
>> /proc/kallsyms and we don't want to break those. A proper testing period
>> through -mm should take care of that, though.
> 
> It's the other way round -- kallsyms changed and that change will likely
> break programs.

I don't have the time right now to try your configuration and pinpoint 
the problem, but if you can come up with a plan, like: "we need to 
filter out symbols from the output of "nm" whose type is 'N'", I'll be 
more than happy to provide a patch to fix it...

-- 
Paulo Marques - www.grupopie.com

"Nostalgia isn't what it used to be."
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/