/proc/kallsyms显示value全部为0

今天一个同事问我cat /proc/kallsyms显示value全部为0.我在手机端试了一下，果然如此。

切换到root用户运行，依然是0. 感到十分奇怪，因为内核发生crash或者打开trace的时候，都是调用的sprint_ symbol来打印的.为啥内核可以，用户态cat就不行呢？

最终从一篇博客http://www.cnblogs.com/richardustc/archive/2013/04/25/3043674.html中看到了关于内核控制变量/porc/sys/kernel/kptr_restrict。
从内核文档Documentation/sysctl/kernel.txt中可以看到kptr_restrict用于控制内核的一些输出打印。

Documentation/printk-formats.txt有更加详细的描述，除了我们平时遇到的一些打印格式之外，还有一些比较特殊的格式（我以前没注意到）。

375==============================================================
376
377kptr_restrict:
378
379This toggle indicates whether restrictions are placed on
380exposing kernel addresses via /proc and other interfaces.
381
382When kptr_restrict is set to (0), the default, there are no restrictions.
383
384When kptr_restrict is set to (1), kernel pointers printed using the %pK
385format specifier will be replaced with 0's unless the user has CAP_SYSLOG
386and effective user and group ids are equal to the real ids. This is
387because %pK checks are done at read() time rather than open() time, so
388if permissions are elevated between the open() and the read() (e.g via
389a setuid binary) then %pK will not leak kernel pointers to unprivileged
390users. Note, this is a temporary solution only. The correct long-term
391solution is to do the permission checks at open() time. Consider removing
392world read permissions from files that use %pK, and using dmesg_restrict
393to protect against uses of %pK in dmesg(8) if leaking kernel pointer
394values to unprivileged users is a concern.
395
396When kptr_restrict is set to (2), kernel pointers printed using
397%pK will be replaced with 0's regardless of privileges.

/proc/sys/kernel # cat kptr_restrict
2
/proc/sys/kernel # su
su
/proc/sys/kernel # echo 0 > kptr_restrict
/proc/sys/kernel # cat kptr_restrict
cat kptr_restrict
0
/proc/sys/kernel # cat /proc/kallsyms | grep wake_up_process
cat /proc/kallsyms | grep wake_up_process
ffffffc0002500f4 T wake_up_process

这下好了～～