Re: [PATCH v2] ARM: mm: flip priority of CONFIG_DEBUG_RODATA

[Laura Abbott]

On 12/23/2015 11:51 AM, Tony Lindgren wrote:
> * Kees Cook <keescook@xxxxxxxxxxxx> [151202 12:31]:
> > The use of CONFIG_DEBUG_RODATA is generally seen as an essential part of
> > kernel self-protection:
> > http://www.openwall.com/lists/kernel-hardening/2015/11/30/13
> > Additionally, its name has grown to mean things beyond just rodata. To
> > get ARM closer to this, we ought to rearrange the names of the configs
> > that control how the kernel protects its memory. What was called
> > CONFIG_ARM_KERNMEM_PERMS is really doing the work that other architectures
> > call CONFIG_DEBUG_RODATA.
> >
> > This redefines CONFIG_DEBUG_RODATA to actually do the bulk of the
> > ROing (and NXing). In the place of the old CONFIG_DEBUG_RODATA, use
> > CONFIG_DEBUG_ALIGN_RODATA, since that's what the option does: adds
> > section alignment for making rodata explicitly NX, as arm does not split
> > the page tables like arm64 does without _ALIGN_RODATA.
>
> Also all omap3 boards are now oopsing in Linux next if PM is enabled:
>
> [   18.549865] Unable to handle kernel paging request at virtual address c01237dc
> [   18.557830] pgd = cf704000
> [   18.560974] [c01237dc] *pgd=8000041e(bad)
> [   18.565765] Internal error: Oops: 80d [#1] SMP ARM
> [   18.571105] Modules linked in: ledtrig_default_on leds_gpio led_class rtc_twl twl4030_wdt
> [   18.581024] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.4.0-rc6-00003-g1bb2057 #2973
> [   18.589508] Hardware name: Generic OMAP36xx (Flattened Device Tree)
> [   18.596466] task: c0c06638 ti: c0c00000 task.ti: c0c00000
> [   18.602539] PC is at wait_dll_lock_timed+0x8/0x14
> [   18.607849] LR is at save_context_wfi+0x24/0x28
> [   18.612976] pc : [<c0123750>]    lr : [<c01236b0>]    psr: 600e0093
> [   18.612976] sp : c0c01ea0  ip : c0c028d4  fp : 00000002
> [   18.625549] r10: 00000000  r9 : ffffffff  r8 : 00000000
> [   18.631378] r7 : c01237d8  r6 : 00000003  r5 : 0000000a  r4 : 00000001
> [   18.638610] r3 : 00000004  r2 : 00000006  r1 : f03fe03a  r0 : 0a000023
> [   18.645843] Flags: nZCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment none
> [   18.653839] Control: 10c53879  Table: 8f704019  DAC: 00000051
> [   18.660217] Process swapper/0 (pid: 0, stack limit = 0xc0c00218)
> [   18.666900] Stack: (0xc0c01ea0 to 0xc0c02000)
> [   18.671936] 1ea0: 00000030 c0c01efc 00000003 00000001 00000000 c0c0a0a0 c0c028d4 00000000
> [   18.681060] 1ec0: c0122ef8 00000000 c010d210 8f0b0000 c0c01efc 80119dc0 00000000 00000000
> [   18.690185] 1ee0: 00000000 00000051 80004019 10c5387d 000000e2 00f00000 00000000 c0c06638
> [   18.699279] 1f00: cf6a4e00 00000003 00000001 00000000 c0c0a0a0 00000000 00000000 c010d3bc
> [   18.708404] 1f20: c0cbd460 c0cbdd14 00000003 c012308c 00000003 c0c09f90 c0cbdd54 00000000
> [   18.717529] 1f40: 00000001 c0124584 51b8dc60 00000004 c0cb8a9c c0c09fa0 cfb3ba58 c05a8e14
> [   18.726654] 1f60: 008a43a0 00000000 51b8dc60 00000004 51b8dc60 00000004 c0c029ec c0c00000
> [   18.735778] 1f80: c0c029ec 00000000 c0cb8a9c cfb3ba58 c0c09fa0 c0c0298c c0b6ea50 c017bbb4
> [   18.744934] 1fa0: c0740760 c0b6a4e4 c0cbd000 ffffffff cfb473c0 c0b00c34 ffffffff ffffffff
> [   18.754058] 1fc0: 00000000 c0b0066c 00000000 c0b4fa48 00000000 c0cbd214 c0c0296c c0b4fa44
> [   18.763183] 1fe0: c0c08208 80004059 413fc082 00000000 00000000 8000807c 00000000 00000000
> [   18.772308] [<c0123750>] (wait_dll_lock_timed) from [<c0c0a0a0>] (omap3_idle_driver+0x100/0x33c)
> [   18.782043] Code: 1a000019 e28f708c e59f408c e2844001 (e5874004)
>
> Reverting the $subject patch fixes the issue.
>
> Regards,
>
> Tony

Looks like a case similar to Geert's

        adr     r7, kick_counter
wait_dll_lock_timed:
        ldr     r4, wait_dll_lock_counter
        add     r4, r4, #1
        str     r4, [r7, #wait_dll_lock_counter - kick_counter]
        ldr     r4, sdrc_dlla_status
        /* Wait 20uS for lock */
        mov     r6, #8


kick_counter and wait_dll_lock_counter are in the text section which is marked read only.
They need to be moved to the data section along with a few other variables from what I
can tell (maybe those are read only?).

I suspect this is going to be a common issue with suspend/resume code paths since those
are hand written assembly.

Thanks,
Laura
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/