| 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
| ||
|
Message-ID: <20070924205506.GC31899@frankl.hpl.hp.com> Date: Mon, 24 Sep 2007 13:55:06 -0700 From: Stephane Eranian <eranian@....hp.com> To: linux-kernel@...r.kernel.org Cc: Stephane Eranian <eranian@....hp.com>, perfmon@...ali.hpl.hp.com Subject: /proc/kallsyms and symbol size Hello, Many monitoring tools use /proc/kallsyms to build a symbol table for the kernel. This technique has the advantage that it does not require root privileges, nor an up-to-date /boot/System.map, nor a decompressed kernel in /boot. The problem is that /proc/kallsyms does not report the size of the symbols. Yet, the information is available in the kernel as it is used by functions such as __print_symbol(). Having the size is useful to correlate the address obtained is a sample with a symbol name. Most tools use an approximation which assumes symbols are contiguous to estimate the size. Apart from the backward compatbility problem for the output of kallsyms, what would be the major issue with exposing this information? Thanks. -- -Stephane - 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/
Powered by blists - more mailing lists