Bug 113372 - Missing /proc/kallsyms in 2.6.1-1.126
Missing /proc/kallsyms in 2.6.1-1.126
Status: CLOSED NOTABUG
Product: Red Hat Raw Hide
Classification: Retired
Component: kernel (Show other bugs)
1.0
All Linux
medium Severity high
: ---
: ---
Assigned To: Arjan van de Ven
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-01-13 06:04 EST by Didier
Modified: 2007-04-18 13:01 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-01-14 16:32:04 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Didier 2004-01-13 06:04:23 EST
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
Comment 1 Arjan van de Ven 2004-01-14 04:40:14 EST
sounds like vmware is being naughty, /proc/kallsyms is not for
building modules against....
Comment 2 Didier 2004-01-14 08:53:25 EST
(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 ?


Comment 3 Arjan van de Ven 2004-01-14 08:58:59 EST
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.
Comment 4 Didier 2004-01-14 09:18:45 EST
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.
Comment 5 Didier 2004-01-14 09:26:56 EST
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 ?

Comment 6 Arjan van de Ven 2004-01-14 09:32:07 EST
probably.

Btw "CONFIG_KALLSYMS=y" is to enable symbolic backtraces/oopses, not
for enabling /proc/kallsyms
Comment 7 Didier 2004-01-14 14:21:22 EST
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 !
Comment 8 Didier 2004-01-14 16:32:04 EST
Unofficial patches exist (http://platan.vc.cvut.cz/ftp/pub/vmware/)
which seem to let VMware WS interoperate with kernel 2.6.1.

Note You need to log in before you can comment on or make changes to this bug.