Description of problem: After installing and booting kernel-2.6.1-1.126, proc entry /proc/kallsyms is missing, resulting in lots of trouble (e.g. no compilation of VMware modules). I tested this on two different workstations, and on one workstation with a recompiled kernel (from kernel-source.rpm). Version-Release number of selected component (if applicable): kernel-2.6.1-1.126 How reproducible: Always. Additional info: kernel config file : CONFIG_KALLSYMS=y
sounds like vmware is being naughty, /proc/kallsyms is not for building modules against....
(Disclaimer : I am not a kernel guru, just an ordinary end-user) Having a quick look at the vmware configuration script, I suppose they use /proc/kallsyms to check whether certain prerequisites are present in the current running kernel. Nevertheless, going from 2.4 -> 2.6 needed a modification of that script (/proc/ksyms -> /proc/kallsyms), and this worked perfectly up until 2.6.1-1.126. Is there an intermediate workaround to enable /proc/kallsyms, or can its absence be accounted to e.g. a kernel build bug ?
it's on purpose; /proc/kallsyms is an information leak that gives lots of detailed information about kernel internals that is useful for security exploits.
Thank you for the swift information (I googled some days before filing this bug report, but could not find anything appropriate). Is there a way to go back to the old behaviour (while I file a bug report with VMware), allowing me (and probably a lot of cutting-edge VMware users) in the mean time to build the VMware modules ? Otherwise, the "CONFIG_KALLSYMS=y" kernel build directive seems quite obsolete to me.
WRT comment #4 : My sincere apologies to follow up on my own comment and wasting your time, but does it suffice to add : "__initcall(kallsyms_init);" in kernel/kallsyms.c and rebuild bzImage to enable /proc/kallsyms ?
probably. Btw "CONFIG_KALLSYMS=y" is to enable symbolic backtraces/oopses, not for enabling /proc/kallsyms
Including "__initcall(kallsyms_init);" at the end of kallsyms.c enables /proc/kallsyms. However, compiling and insmoding the VMware vmmon.o module now oopses the kernel (which did not happen with 2.6.0-1.104) : "Debug: sleeping function called from invalid context at include/linux/rwsem.h:43" As I have a complete call trace available, I'm wondering whether to file a (separate) Bugzilla report, or close this one and not bother (vmmon.o taints the kernel). Thanks for any advice in this, and for the truly great product that RH(E)L/FC is !
Unofficial patches exist (http://platan.vc.cvut.cz/ftp/pub/vmware/) which seem to let VMware WS interoperate with kernel 2.6.1.