Pushback on pointer hiding

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 /proc 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.

---

(Log in to post comments)