There has been a determined effort over the last few kernel development
cycles to eliminate the leakage of kernel addresses into user space. A
determined attacker, it is thought, could use address information to figure
out where important data structures are in memory; that is an important
step toward corrupting those structures. So it arguably makes sense to
avoid exposing kernel addresses in
files and other places
where the kernel provides information to user space.
Early in the 2.6.39 development cycle, a patch was applied to censor kernel
addresses appearing in /proc/kallsyms and /proc/modules.
On an affected system, /proc/kallsyms looks like this:
0000000000000000 V callchain_recursion
0000000000000000 V rotation_list
0000000000000000 V perf_cgroup_events
0000000000000000 V nr_bp_flexible
0000000000000000 V nr_task_bp_pinned
0000000000000000 V nr_cpu_bp_pinned
Needless to say, zeroing out the address information makes this file rather
less useful than it had been previously. What drew attention to this
change, though, was a report that perf
produces bogus information in this situation. It seems that perf was not
detecting the hiding of kernel addresses, so it happily went forward with
all those zero values.
That is obviously a bug in perf; it will be fixed shortly. But a number of
developers complained about the practice of hiding kernel addresses by
default. That behavior makes the system less useful than it was before,
and will certainly cause other surprises. People who want whatever extra
security is provided by this behavior should have to ask for it explicitly,
it was said; David Miller pointed out that
other security technologies - like SELinux - are not turned on by default.
That argument won the day, so the final 2.6.39 release will not hide kernel
pointers by default. Anybody wanting pointer hiding should turn it on by
setting the kernel.kptr_restrict knob to 1.
to post comments)