[PATCH] Arm: mm: ftrace: Only set text back to ro after kernel has been marked ro

On Fri, 29 Jun 2018 16:47:14 +0200
Matthias Reichl [off-list ref] wrote:

On Tue, Dec 05, 2017 at 12:14:46PM -0800, Kees Cook wrote:

quoted

On Tue, Dec 5, 2017 at 12:09 PM, Russell King - ARM Linux
[off-list ref] wrote:  

quoted

On Tue, Dec 05, 2017 at 11:35:59AM -0800, Kees Cook wrote:  

quoted

We don't _need_ to, but they're all contiguous, so the ro_perms array
used by set_kernel_text_*() is actually only a single entry:

static struct section_perm ro_perms[] = {
        /* Make kernel code and rodata RX (set RO). */
        {
                .name   = "text/rodata RO",
                .start  = (unsigned long)_stext,
                .end    = (unsigned long)__init_begin,
...  

Well, they may not be contiguous - it depends on DEBUG_ALIGN_RODATA.  

Maybe I'm picking a slightly wrong word. I guess I meant adjacent. The
range _stext to __init_begin is all read-only, though there may be
padding (controlled by DEBUG_ALIGN_RODATA), to allow a split for NX
markings on rodata.
  

quoted

Either way, we have __start_rodata_section_aligned, which is either
the start of the read-only data section, or the start of the first
section beyond __start_rodata if DEBUG_ALIGN_RODATA is not set.

Given that __start_rodata_section_aligned will always be less than
__init_begin, is there any reason not to make the above end at
__start_rodata_section_aligned, thereby allowing more of the read-only
data (in the case of DEBUG_ALIGN_RODATA=n) or all of the read-only
data (in the case of DEBUG_ALIGN_RODATA=y) to remain write-protected?  

Sure, there's no reason not to split this into two entries. It'll
require some reworking of the function calls to get it right,
obviously.  

Gentle ping, arm is still oopsing when the function tracer is
enabled at boot time.

I take it that my patch never got applied:

 http://lkml.kernel.org/r/20180621124710.453ee0ae at gandalf.local.home

-- Steve

Tested on bcm2835 (RPiB+) with current mainline tree
(githash 90368a37fbbe) and bcm2835_defconfig.

arm64 seems to be fine, tested on bcm2837 (RPi3) with same tree and
arm64 defconfig plus function tracer enabled.