Overwrite detection for kernel text and read-only data


 * Summary: Overwrite detection for kernel text and read-only data
 * Proposer: Tim Bird, Sony Mobile
 * Status: Selected to be sponsored by the CE Workgroup

Description
In embedded systems, drivers or other subsystems can easily (mistakenly) overwrite kernel text or kernel read-only area. It can be very difficult to debug who is overwriting kernel.

It would be nice to have some mechanism to detect kernel overwriting or corruption by setting a write-protect attribute in page tables for kernel text or read-only data. x86 already has this feature in the form of CONFIG_DEBUG_RODATA. This project would consist of providing support for this feature in ARM, as well as possibly creating exceptions for code which needs to modify the kernel text at runtime, such as Kprobe or ftrace.

A significant difficulty is that the kernel memory for ARM is currently mapped by section (that is, using 1MB sections). This means that small memory areas cannot be individually re-mapped RO on page boundaries. If the kernel has code which must be writable for some reason, then with that current mapping, at least a 1MB section would be used for that writable code. Likely, the linking sections of the source would have to be modified to support RO/RW attributes, to coalesce the sections into correct categories.

Related work

 * ARM Linux Embedded memory protection techniques
 * Presentation by Prabindh Sundareson in May, 2013 about the status of ARM memory protection features.
 * Russel King comments on kernel memory and RO mapping: http://www.spinics.net/lists/arm-kernel/msg120951.html
 * The implementation of CONFIG_DEBUG_RODATA in x86 may have some useful information.

Scope
Unknown

Contractor Candidates
None yet.

Comments
Tim Bird writes: Sony has patches to support 4KB mappings for the kernel, for ARM, which they've been using internally. These might be useful for this feature. Actually - Sony has patches for 3.0 for this entire feature, but they are likely not mainlinable in their current form (and this feature may not be mainlinable in any form, depending on the whims of the maintainers.)