Difference between revisions of "Overwrite detection for kernel text and read-only data"

From eLinux.org
Jump to: navigation, search
(add comment by Tim about Sony 4K mapping patches)
(extra commentary)
 
(One intermediate revision by one other user not shown)
Line 1: Line 1:
 
; Summary: Overwrite detection for kernel text and read-only data
 
; Summary: Overwrite detection for kernel text and read-only data
 
 
; Proposer: Tim Bird, Sony Mobile
 
; Proposer: Tim Bird, Sony Mobile
 +
; Status: Selected to be sponsored by the CE Workgroup
  
 
== Description ==
 
== Description ==
Line 41: Line 41:
 
  which they've been using internally.  These might be useful
 
  which they've been using internally.  These might be useful
 
  for this feature.
 
  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.)
 +
  
 
[[Category:Project proposals 2013]]
 
[[Category:Project proposals 2013]]

Latest revision as of 00:15, 18 January 2014

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

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.)