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

[Kees Cook]

On Mon, Jan 4, 2016 at 2:07 PM, Russell King - ARM Linux
 wrote:
> On Mon, Jan 04, 2016 at 12:34:28PM -0800, Kees Cook wrote:
>> On Wed, Dec 23, 2015 at 4:34 PM, Russell King - ARM Linux
>>  wrote:
>> > On Wed, Dec 23, 2015 at 04:11:22PM -0800, Tony Lindgren wrote:
>> >> * Nicolas Pitre  [151223 13:45]:
>> >> > We fixed a bunch of similar issues where code was located in the .data
>> >> > section for ease of use from assembly code.  See commit b4e61537 and
>> >> > d0776aff for example.
>> >>
>> >> Thanks hey some assembly fun for the holidays :) I also need to check what
>> >> all gets relocated to SRAM here.
>> >>
>> >> In any case, seems like the $subject patch is too intrusive for v4.5 at
>> >> this point.
>> >
>> > Given Christmas and an unknown time between that and the merge window
>> > actually opening, I decided Tuesday would be the last day I take any
>> > patches into my tree - and today would be the day that I drop anything
>> > that causes problems.
>> >
>> > So, I've already dropped this, so tomorrow's linux-next should not have
>> > this change.
>> >
>> > You'll still see breakage if people enable RODATA though, but that's no
>> > different from previous kernels.
>>
>> Ugh, sorry for the breakage.
>>
>> Should this patch stay as-is and people will fix their various RODATA
>> failures during the next devel window, or should I remove the "default
>> y if CPU_V7"?
>
> I think we'll keep it as-is, and have another go with it at -rc1 time,
> when people have ample chance to then queue up fixes.
>
> They'll have had notice of it, so there's no excuse folk can't work on
> the problem in the mean time.  (But, of course, they won't...)

Hi,

Just checking on this -- I resent it to the patch tracker at -rc1
time. Is this waiting for the other fixes to land first, or is there
something I should be doing?

Thanks!

-Kees

-- 
Kees Cook
Chrome OS & Brillo Security

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

[Kees Cook]

On Mon, Jan 4, 2016 at 2:07 PM, Russell King - ARM Linux
 wrote:
> On Mon, Jan 04, 2016 at 12:34:28PM -0800, Kees Cook wrote:
>> On Wed, Dec 23, 2015 at 4:34 PM, Russell King - ARM Linux
>>  wrote:
>> > On Wed, Dec 23, 2015 at 04:11:22PM -0800, Tony Lindgren wrote:
>> >> * Nicolas Pitre  [151223 13:45]:
>> >> > We fixed a bunch of similar issues where code was located in the .data
>> >> > section for ease of use from assembly code.  See commit b4e61537 and
>> >> > d0776aff for example.
>> >>
>> >> Thanks hey some assembly fun for the holidays :) I also need to check what
>> >> all gets relocated to SRAM here.
>> >>
>> >> In any case, seems like the $subject patch is too intrusive for v4.5 at
>> >> this point.
>> >
>> > Given Christmas and an unknown time between that and the merge window
>> > actually opening, I decided Tuesday would be the last day I take any
>> > patches into my tree - and today would be the day that I drop anything
>> > that causes problems.
>> >
>> > So, I've already dropped this, so tomorrow's linux-next should not have
>> > this change.
>> >
>> > You'll still see breakage if people enable RODATA though, but that's no
>> > different from previous kernels.
>>
>> Ugh, sorry for the breakage.
>>
>> Should this patch stay as-is and people will fix their various RODATA
>> failures during the next devel window, or should I remove the "default
>> y if CPU_V7"?
>
> I think we'll keep it as-is, and have another go with it at -rc1 time,
> when people have ample chance to then queue up fixes.
>
> They'll have had notice of it, so there's no excuse folk can't work on
> the problem in the mean time.  (But, of course, they won't...)

Hi,

Just checking on this -- I resent it to the patch tracker at -rc1
time. Is this waiting for the other fixes to land first, or is there
something I should be doing?

Thanks!

-Kees

-- 
Kees Cook
Chrome OS & Brillo Security

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

[Russell King - ARM Linux]

On Mon, Jan 04, 2016 at 12:34:28PM -0800, Kees Cook wrote:
> On Wed, Dec 23, 2015 at 4:34 PM, Russell King - ARM Linux
>  wrote:
> > On Wed, Dec 23, 2015 at 04:11:22PM -0800, Tony Lindgren wrote:
> >> * Nicolas Pitre  [151223 13:45]:
> >> > We fixed a bunch of similar issues where code was located in the .data
> >> > section for ease of use from assembly code.  See commit b4e61537 and
> >> > d0776aff for example.
> >>
> >> Thanks hey some assembly fun for the holidays :) I also need to check what
> >> all gets relocated to SRAM here.
> >>
> >> In any case, seems like the $subject patch is too intrusive for v4.5 at
> >> this point.
> >
> > Given Christmas and an unknown time between that and the merge window
> > actually opening, I decided Tuesday would be the last day I take any
> > patches into my tree - and today would be the day that I drop anything
> > that causes problems.
> >
> > So, I've already dropped this, so tomorrow's linux-next should not have
> > this change.
> >
> > You'll still see breakage if people enable RODATA though, but that's no
> > different from previous kernels.
> 
> Ugh, sorry for the breakage.
> 
> Should this patch stay as-is and people will fix their various RODATA
> failures during the next devel window, or should I remove the "default
> y if CPU_V7"?

I think we'll keep it as-is, and have another go with it at -rc1 time,
when people have ample chance to then queue up fixes.

They'll have had notice of it, so there's no excuse folk can't work on
the problem in the mean time.  (But, of course, they won't...)

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Kees Cook]

On Wed, Dec 23, 2015 at 4:34 PM, Russell King - ARM Linux
 wrote:
> On Wed, Dec 23, 2015 at 04:11:22PM -0800, Tony Lindgren wrote:
>> * Nicolas Pitre  [151223 13:45]:
>> > We fixed a bunch of similar issues where code was located in the .data
>> > section for ease of use from assembly code.  See commit b4e61537 and
>> > d0776aff for example.
>>
>> Thanks hey some assembly fun for the holidays :) I also need to check what
>> all gets relocated to SRAM here.
>>
>> In any case, seems like the $subject patch is too intrusive for v4.5 at
>> this point.
>
> Given Christmas and an unknown time between that and the merge window
> actually opening, I decided Tuesday would be the last day I take any
> patches into my tree - and today would be the day that I drop anything
> that causes problems.
>
> So, I've already dropped this, so tomorrow's linux-next should not have
> this change.
>
> You'll still see breakage if people enable RODATA though, but that's no
> different from previous kernels.

Ugh, sorry for the breakage.

Should this patch stay as-is and people will fix their various RODATA
failures during the next devel window, or should I remove the "default
y if CPU_V7"?

-Kees

-- 
Kees Cook
Chrome OS & Brillo Security
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Kees Cook]

On Wed, Dec 23, 2015 at 4:34 PM, Russell King - ARM Linux
 wrote:
> On Wed, Dec 23, 2015 at 04:11:22PM -0800, Tony Lindgren wrote:
>> * Nicolas Pitre  [151223 13:45]:
>> > We fixed a bunch of similar issues where code was located in the .data
>> > section for ease of use from assembly code.  See commit b4e61537 and
>> > d0776aff for example.
>>
>> Thanks hey some assembly fun for the holidays :) I also need to check what
>> all gets relocated to SRAM here.
>>
>> In any case, seems like the $subject patch is too intrusive for v4.5 at
>> this point.
>
> Given Christmas and an unknown time between that and the merge window
> actually opening, I decided Tuesday would be the last day I take any
> patches into my tree - and today would be the day that I drop anything
> that causes problems.
>
> So, I've already dropped this, so tomorrow's linux-next should not have
> this change.
>
> You'll still see breakage if people enable RODATA though, but that's no
> different from previous kernels.

Ugh, sorry for the breakage.

Should this patch stay as-is and people will fix their various RODATA
failures during the next devel window, or should I remove the "default
y if CPU_V7"?

-Kees

-- 
Kees Cook
Chrome OS & Brillo Security
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Russell King - ARM Linux]

On Mon, Jan 04, 2016 at 12:34:28PM -0800, Kees Cook wrote:
> On Wed, Dec 23, 2015 at 4:34 PM, Russell King - ARM Linux
>  wrote:
> > On Wed, Dec 23, 2015 at 04:11:22PM -0800, Tony Lindgren wrote:
> >> * Nicolas Pitre  [151223 13:45]:
> >> > We fixed a bunch of similar issues where code was located in the .data
> >> > section for ease of use from assembly code.  See commit b4e61537 and
> >> > d0776aff for example.
> >>
> >> Thanks hey some assembly fun for the holidays :) I also need to check what
> >> all gets relocated to SRAM here.
> >>
> >> In any case, seems like the $subject patch is too intrusive for v4.5 at
> >> this point.
> >
> > Given Christmas and an unknown time between that and the merge window
> > actually opening, I decided Tuesday would be the last day I take any
> > patches into my tree - and today would be the day that I drop anything
> > that causes problems.
> >
> > So, I've already dropped this, so tomorrow's linux-next should not have
> > this change.
> >
> > You'll still see breakage if people enable RODATA though, but that's no
> > different from previous kernels.
> 
> Ugh, sorry for the breakage.
> 
> Should this patch stay as-is and people will fix their various RODATA
> failures during the next devel window, or should I remove the "default
> y if CPU_V7"?

I think we'll keep it as-is, and have another go with it at -rc1 time,
when people have ample chance to then queue up fixes.

They'll have had notice of it, so there's no excuse folk can't work on
the problem in the mean time.  (But, of course, they won't...)

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Russell King - ARM Linux]

On Wed, Dec 23, 2015 at 04:11:22PM -0800, Tony Lindgren wrote:
> * Nicolas Pitre  [151223 13:45]:
> > We fixed a bunch of similar issues where code was located in the .data 
> > section for ease of use from assembly code.  See commit b4e61537 and 
> > d0776aff for example.
> 
> Thanks hey some assembly fun for the holidays :) I also need to check what
> all gets relocated to SRAM here.
> 
> In any case, seems like the $subject patch is too intrusive for v4.5 at
> this point.

Given Christmas and an unknown time between that and the merge window
actually opening, I decided Tuesday would be the last day I take any
patches into my tree - and today would be the day that I drop anything
that causes problems.

So, I've already dropped this, so tomorrow's linux-next should not have
this change.

You'll still see breakage if people enable RODATA though, but that's no
different from previous kernels.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Tony Lindgren]

* Nicolas Pitre  [151223 13:45]:
> On Wed, 23 Dec 2015, Tony Lindgren wrote:
> 
> > Hi,
> > 
> > * Laura Abbott  [151223 12:31]:
> > > 
> > > 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?).
> > 
> > Thanks for looking, yeah so it seem.
> > 
> > > I suspect this is going to be a common issue with suspend/resume code 
> > > paths since those
> > > are hand written assembly.
> > 
> > Yes I suspect we have quite a few cases like this.
> 
> We fixed a bunch of similar issues where code was located in the .data 
> section for ease of use from assembly code.  See commit b4e61537 and 
> d0776aff for example.

Thanks hey some assembly fun for the holidays :) I also need to check what
all gets relocated to SRAM here.

In any case, seems like the $subject patch is too intrusive for v4.5 at
this point.

Regards,

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

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

[Nicolas Pitre]

On Wed, 23 Dec 2015, Tony Lindgren wrote:

> Hi,
> 
> * Laura Abbott  [151223 12:31]:
> > 
> > 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?).
> 
> Thanks for looking, yeah so it seem.
> 
> > I suspect this is going to be a common issue with suspend/resume code paths 
> > since those
> > are hand written assembly.
> 
> Yes I suspect we have quite a few cases like this.

We fixed a bunch of similar issues where code was located in the .data 
section for ease of use from assembly code.  See commit b4e61537 and 
d0776aff for example.


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

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

[Tony Lindgren]

Hi,

* Laura Abbott  [151223 12:31]:
> 
> 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?).

Thanks for looking, yeah so it seem.

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

Yes I suspect we have quite a few cases like this.

Regards,

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

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

[Laura Abbott]

On 12/23/2015 12:15 PM, Russell King - ARM Linux wrote:

On Wed, Dec 02, 2015 at 12:27:25PM -0800, Kees Cook wrote:

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.


Kees,

There is a subtle problem with the kernel memory permissions and the
DMA debugging.

DMA debugging checks whether we're trying to do DMA from the kernel
mappings (text, rodata, data etc).  It checks _text.._etext.  However,
when RODATA is enabled, we have about one section between _text and
_stext which are freed into the kernel's page pool, and then become
available for allocation and use for DMA.

This then causes the DMA debugging sanity check to fire.

So, I think I'll revert this change for the time being as it seems to
be causing many people problems, and having this enabled is creating
extra warnings when kernel debug options are enabled along with it.

Sorry.



in include/asm-generic/sections.h:

/*
 * Usage guidelines:
 * _text, _data: architecture specific, don't use them in arch-independent code
 * [_stext, _etext]: contains .text.* sections, may also contain .rodata.*
 *   and/or .init.* sections


So based on that comment it seems like the dma-debug should be checking for
_stext not _text since only _stext is guaranteed across all architectures.
I'll submit a patch to dma-debug.c if this seems appropriate or if you
haven't done so already.

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

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  [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=841e(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-3-g1bb2057 #2973
[   18.589508] Hardware name: Generic OMAP36xx (Flattened Device Tree)
[   18.596466] task: c0c06638 ti: c0c0 task.ti: c0c0
[   18.602539] PC is at wait_dll_lock_timed+0x8/0x14
[   18.607849] LR is at save_context_wfi+0x24/0x28
[   18.612976] pc : []lr : []psr: 600e0093
[   18.612976] sp : c0c01ea0  ip : c0c028d4  fp : 0002
[   18.625549] r10:   r9 :   r8 : 
[   18.631378] r7 : c01237d8  r6 : 0003  r5 : 000a  r4 : 0001
[   18.638610] r3 : 0004  r2 : 0006  r1 : f03fe03a  r0 : 0a23
[   18.645843] Flags: nZCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment 
none
[   18.653839] Control: 10c53879  Table: 8f704019  DAC: 0051
[   18.660217] Process swapper/0 (pid: 0, stack limit = 0xc0c00218)
[   18.666900] Stack: (0xc0c01ea0 to 0xc0c02000)
[   18.671936] 1ea0: 0030 c0c01efc 0003 0001  c0c0a0a0 
c0c028d4 
[   18.681060] 1ec0: c0122ef8  c010d210 8f0b c0c01efc 80119dc0 
 
[   18.690185] 1ee0:  0051 80004019 10c5387d 00e2 00f0 
 c0c06638
[   18.699279] 1f00: cf6a4e00 0003 0001  c0c0a0a0  
 c010d3bc
[   18.708404] 1f20: c0cbd460 c0cbdd14 0003 c012308c 0003 c0c09f90 
c0cbdd54 
[   18.717529] 1f40: 0001 c0124584 51b8dc60 0004 c0cb8a9c c0c09fa0 
cfb3ba58 c05a8e14
[   18.726654] 1f60: 008a43a0  51b8dc60 0004 51b8dc60 0004 
c0c029ec c0c0
[   18.735778] 1f80: c0c029ec  c0cb8a9c cfb3ba58 c0c09fa0 c0c0298c 
c0b6ea50 c017bbb4
[   18.744934] 1fa0: c0740760 c0b6a4e4 c0cbd000  cfb473c0 c0b00c34 
 
[   18.754058] 1fc0:  c0b0066c  c0b4fa48  c0cbd214 
c0c0296c c0b4fa44
[   18.763183] 1fe0: c0c08208 80004059 413fc082   8000807c 
 
[   18.772308] [] (wait_dll_lock_timed) from [] 
(omap3_idle_driver+0x100/0x33c)
[   18.782043] Code: 1a19 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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Tony Lindgren]

* Russell King - ARM Linux  [151223 12:01]:
> On Wed, Dec 23, 2015 at 11:51:29AM -0800, Tony Lindgren wrote:
> > Also all omap3 boards are now oopsing in Linux next if PM is enabled:
> 
> I'm not sure that's entirely true.  My LDP3430 works fine with this
> change in place, and that has CONFIG_PM=y.  See my nightly build/boot
> results, which includes an attempt to enter hibernation.  Remember
> that last night's results are from my tree plus arm-soc's for-next.

Right but you don't have any deeper idle states enabled for your
old ldp, see the script below. It may not work properly on your ldp
because of the old silicon revision of the SoC..

> Maybe there's some other change in linux-next which, when combined
> with this change, is provoking it?

Well it seems to be the new default Kconfig options selected by
default as Geert is saying?

And it seems to require off mode enabled for idle to hit it, retention
idle does not seem to trigger it.

Regards,

Tony


8< -
#!/bin/bash

uarts=$(find /sys/class/tty/tty[SO]*/device/power/ -type d)
for uart in $uarts; do
echo 3000 > $uart/autosuspend_delay_ms 2>&1
done

uarts=$(find /sys/class/tty/tty[SO]*/power/ -type d 2>/dev/null)
for uart in $uarts; do
echo enabled > $uart/wakeup 2>&1
echo auto > $uart/control 2>&1
done

echo 1 > /sys/kernel/debug/pm_debug/enable_off_mode
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Russell King - ARM Linux]

On Wed, Dec 02, 2015 at 12:27:25PM -0800, Kees Cook wrote:
> 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.

Kees,

There is a subtle problem with the kernel memory permissions and the
DMA debugging.

DMA debugging checks whether we're trying to do DMA from the kernel
mappings (text, rodata, data etc).  It checks _text.._etext.  However,
when RODATA is enabled, we have about one section between _text and
_stext which are freed into the kernel's page pool, and then become
available for allocation and use for DMA.

This then causes the DMA debugging sanity check to fire.

So, I think I'll revert this change for the time being as it seems to
be causing many people problems, and having this enabled is creating
extra warnings when kernel debug options are enabled along with it.

Sorry.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Russell King - ARM Linux]

On Wed, Dec 23, 2015 at 11:51:29AM -0800, Tony Lindgren wrote:
> Also all omap3 boards are now oopsing in Linux next if PM is enabled:

I'm not sure that's entirely true.  My LDP3430 works fine with this
change in place, and that has CONFIG_PM=y.  See my nightly build/boot
results, which includes an attempt to enter hibernation.  Remember
that last night's results are from my tree plus arm-soc's for-next.

Maybe there's some other change in linux-next which, when combined
with this change, is provoking it?

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Tony Lindgren]

* Kees Cook  [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=841e(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-3-g1bb2057 #2973
[   18.589508] Hardware name: Generic OMAP36xx (Flattened Device Tree)
[   18.596466] task: c0c06638 ti: c0c0 task.ti: c0c0
[   18.602539] PC is at wait_dll_lock_timed+0x8/0x14
[   18.607849] LR is at save_context_wfi+0x24/0x28
[   18.612976] pc : []lr : []psr: 600e0093
[   18.612976] sp : c0c01ea0  ip : c0c028d4  fp : 0002
[   18.625549] r10:   r9 :   r8 : 
[   18.631378] r7 : c01237d8  r6 : 0003  r5 : 000a  r4 : 0001
[   18.638610] r3 : 0004  r2 : 0006  r1 : f03fe03a  r0 : 0a23
[   18.645843] Flags: nZCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment 
none
[   18.653839] Control: 10c53879  Table: 8f704019  DAC: 0051
[   18.660217] Process swapper/0 (pid: 0, stack limit = 0xc0c00218)
[   18.666900] Stack: (0xc0c01ea0 to 0xc0c02000)
[   18.671936] 1ea0: 0030 c0c01efc 0003 0001  c0c0a0a0 
c0c028d4 
[   18.681060] 1ec0: c0122ef8  c010d210 8f0b c0c01efc 80119dc0 
 
[   18.690185] 1ee0:  0051 80004019 10c5387d 00e2 00f0 
 c0c06638
[   18.699279] 1f00: cf6a4e00 0003 0001  c0c0a0a0  
 c010d3bc
[   18.708404] 1f20: c0cbd460 c0cbdd14 0003 c012308c 0003 c0c09f90 
c0cbdd54 
[   18.717529] 1f40: 0001 c0124584 51b8dc60 0004 c0cb8a9c c0c09fa0 
cfb3ba58 c05a8e14
[   18.726654] 1f60: 008a43a0  51b8dc60 0004 51b8dc60 0004 
c0c029ec c0c0
[   18.735778] 1f80: c0c029ec  c0cb8a9c cfb3ba58 c0c09fa0 c0c0298c 
c0b6ea50 c017bbb4
[   18.744934] 1fa0: c0740760 c0b6a4e4 c0cbd000  cfb473c0 c0b00c34 
 
[   18.754058] 1fc0:  c0b0066c  c0b4fa48  c0cbd214 
c0c0296c c0b4fa44
[   18.763183] 1fe0: c0c08208 80004059 413fc082   8000807c 
 
[   18.772308] [] (wait_dll_lock_timed) from [] 
(omap3_idle_driver+0x100/0x33c)
[   18.782043] Code: 1a19 e28f708c e59f408c e2844001 (e5874004)

Reverting the $subject patch fixes the issue.

Regards,

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

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

[Nicolas Pitre]

On Wed, 23 Dec 2015, Tony Lindgren wrote:

> Hi,
> 
> * Laura Abbott  [151223 12:31]:
> > 
> > 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?).
> 
> Thanks for looking, yeah so it seem.
> 
> > I suspect this is going to be a common issue with suspend/resume code paths 
> > since those
> > are hand written assembly.
> 
> Yes I suspect we have quite a few cases like this.

We fixed a bunch of similar issues where code was located in the .data 
section for ease of use from assembly code.  See commit b4e61537 and 
d0776aff for example.


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

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

[Russell King - ARM Linux]

On Wed, Dec 23, 2015 at 04:11:22PM -0800, Tony Lindgren wrote:
> * Nicolas Pitre  [151223 13:45]:
> > We fixed a bunch of similar issues where code was located in the .data 
> > section for ease of use from assembly code.  See commit b4e61537 and 
> > d0776aff for example.
> 
> Thanks hey some assembly fun for the holidays :) I also need to check what
> all gets relocated to SRAM here.
> 
> In any case, seems like the $subject patch is too intrusive for v4.5 at
> this point.

Given Christmas and an unknown time between that and the merge window
actually opening, I decided Tuesday would be the last day I take any
patches into my tree - and today would be the day that I drop anything
that causes problems.

So, I've already dropped this, so tomorrow's linux-next should not have
this change.

You'll still see breakage if people enable RODATA though, but that's no
different from previous kernels.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Tony Lindgren]

* Nicolas Pitre  [151223 13:45]:
> On Wed, 23 Dec 2015, Tony Lindgren wrote:
> 
> > Hi,
> > 
> > * Laura Abbott  [151223 12:31]:
> > > 
> > > 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?).
> > 
> > Thanks for looking, yeah so it seem.
> > 
> > > I suspect this is going to be a common issue with suspend/resume code 
> > > paths since those
> > > are hand written assembly.
> > 
> > Yes I suspect we have quite a few cases like this.
> 
> We fixed a bunch of similar issues where code was located in the .data 
> section for ease of use from assembly code.  See commit b4e61537 and 
> d0776aff for example.

Thanks hey some assembly fun for the holidays :) I also need to check what
all gets relocated to SRAM here.

In any case, seems like the $subject patch is too intrusive for v4.5 at
this point.

Regards,

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

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

[Tony Lindgren]

Hi,

* Laura Abbott  [151223 12:31]:
> 
> 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?).

Thanks for looking, yeah so it seem.

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

Yes I suspect we have quite a few cases like this.

Regards,

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

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

[Russell King - ARM Linux]

On Wed, Dec 02, 2015 at 12:27:25PM -0800, Kees Cook wrote:
> 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.

Kees,

There is a subtle problem with the kernel memory permissions and the
DMA debugging.

DMA debugging checks whether we're trying to do DMA from the kernel
mappings (text, rodata, data etc).  It checks _text.._etext.  However,
when RODATA is enabled, we have about one section between _text and
_stext which are freed into the kernel's page pool, and then become
available for allocation and use for DMA.

This then causes the DMA debugging sanity check to fire.

So, I think I'll revert this change for the time being as it seems to
be causing many people problems, and having this enabled is creating
extra warnings when kernel debug options are enabled along with it.

Sorry.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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  [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=841e(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-3-g1bb2057 #2973
[   18.589508] Hardware name: Generic OMAP36xx (Flattened Device Tree)
[   18.596466] task: c0c06638 ti: c0c0 task.ti: c0c0
[   18.602539] PC is at wait_dll_lock_timed+0x8/0x14
[   18.607849] LR is at save_context_wfi+0x24/0x28
[   18.612976] pc : []lr : []psr: 600e0093
[   18.612976] sp : c0c01ea0  ip : c0c028d4  fp : 0002
[   18.625549] r10:   r9 :   r8 : 
[   18.631378] r7 : c01237d8  r6 : 0003  r5 : 000a  r4 : 0001
[   18.638610] r3 : 0004  r2 : 0006  r1 : f03fe03a  r0 : 0a23
[   18.645843] Flags: nZCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment 
none
[   18.653839] Control: 10c53879  Table: 8f704019  DAC: 0051
[   18.660217] Process swapper/0 (pid: 0, stack limit = 0xc0c00218)
[   18.666900] Stack: (0xc0c01ea0 to 0xc0c02000)
[   18.671936] 1ea0: 0030 c0c01efc 0003 0001  c0c0a0a0 
c0c028d4 
[   18.681060] 1ec0: c0122ef8  c010d210 8f0b c0c01efc 80119dc0 
 
[   18.690185] 1ee0:  0051 80004019 10c5387d 00e2 00f0 
 c0c06638
[   18.699279] 1f00: cf6a4e00 0003 0001  c0c0a0a0  
 c010d3bc
[   18.708404] 1f20: c0cbd460 c0cbdd14 0003 c012308c 0003 c0c09f90 
c0cbdd54 
[   18.717529] 1f40: 0001 c0124584 51b8dc60 0004 c0cb8a9c c0c09fa0 
cfb3ba58 c05a8e14
[   18.726654] 1f60: 008a43a0  51b8dc60 0004 51b8dc60 0004 
c0c029ec c0c0
[   18.735778] 1f80: c0c029ec  c0cb8a9c cfb3ba58 c0c09fa0 c0c0298c 
c0b6ea50 c017bbb4
[   18.744934] 1fa0: c0740760 c0b6a4e4 c0cbd000  cfb473c0 c0b00c34 
 
[   18.754058] 1fc0:  c0b0066c  c0b4fa48  c0cbd214 
c0c0296c c0b4fa44
[   18.763183] 1fe0: c0c08208 80004059 413fc082   8000807c 
 
[   18.772308] [] (wait_dll_lock_timed) from [] 
(omap3_idle_driver+0x100/0x33c)
[   18.782043] Code: 1a19 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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Tony Lindgren]

* Kees Cook  [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=841e(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-3-g1bb2057 #2973
[   18.589508] Hardware name: Generic OMAP36xx (Flattened Device Tree)
[   18.596466] task: c0c06638 ti: c0c0 task.ti: c0c0
[   18.602539] PC is at wait_dll_lock_timed+0x8/0x14
[   18.607849] LR is at save_context_wfi+0x24/0x28
[   18.612976] pc : []lr : []psr: 600e0093
[   18.612976] sp : c0c01ea0  ip : c0c028d4  fp : 0002
[   18.625549] r10:   r9 :   r8 : 
[   18.631378] r7 : c01237d8  r6 : 0003  r5 : 000a  r4 : 0001
[   18.638610] r3 : 0004  r2 : 0006  r1 : f03fe03a  r0 : 0a23
[   18.645843] Flags: nZCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment 
none
[   18.653839] Control: 10c53879  Table: 8f704019  DAC: 0051
[   18.660217] Process swapper/0 (pid: 0, stack limit = 0xc0c00218)
[   18.666900] Stack: (0xc0c01ea0 to 0xc0c02000)
[   18.671936] 1ea0: 0030 c0c01efc 0003 0001  c0c0a0a0 
c0c028d4 
[   18.681060] 1ec0: c0122ef8  c010d210 8f0b c0c01efc 80119dc0 
 
[   18.690185] 1ee0:  0051 80004019 10c5387d 00e2 00f0 
 c0c06638
[   18.699279] 1f00: cf6a4e00 0003 0001  c0c0a0a0  
 c010d3bc
[   18.708404] 1f20: c0cbd460 c0cbdd14 0003 c012308c 0003 c0c09f90 
c0cbdd54 
[   18.717529] 1f40: 0001 c0124584 51b8dc60 0004 c0cb8a9c c0c09fa0 
cfb3ba58 c05a8e14
[   18.726654] 1f60: 008a43a0  51b8dc60 0004 51b8dc60 0004 
c0c029ec c0c0
[   18.735778] 1f80: c0c029ec  c0cb8a9c cfb3ba58 c0c09fa0 c0c0298c 
c0b6ea50 c017bbb4
[   18.744934] 1fa0: c0740760 c0b6a4e4 c0cbd000  cfb473c0 c0b00c34 
 
[   18.754058] 1fc0:  c0b0066c  c0b4fa48  c0cbd214 
c0c0296c c0b4fa44
[   18.763183] 1fe0: c0c08208 80004059 413fc082   8000807c 
 
[   18.772308] [] (wait_dll_lock_timed) from [] 
(omap3_idle_driver+0x100/0x33c)
[   18.782043] Code: 1a19 e28f708c e59f408c e2844001 (e5874004)

Reverting the $subject patch fixes the issue.

Regards,

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

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

[Tony Lindgren]

* Russell King - ARM Linux  [151223 12:01]:
> On Wed, Dec 23, 2015 at 11:51:29AM -0800, Tony Lindgren wrote:
> > Also all omap3 boards are now oopsing in Linux next if PM is enabled:
> 
> I'm not sure that's entirely true.  My LDP3430 works fine with this
> change in place, and that has CONFIG_PM=y.  See my nightly build/boot
> results, which includes an attempt to enter hibernation.  Remember
> that last night's results are from my tree plus arm-soc's for-next.

Right but you don't have any deeper idle states enabled for your
old ldp, see the script below. It may not work properly on your ldp
because of the old silicon revision of the SoC..

> Maybe there's some other change in linux-next which, when combined
> with this change, is provoking it?

Well it seems to be the new default Kconfig options selected by
default as Geert is saying?

And it seems to require off mode enabled for idle to hit it, retention
idle does not seem to trigger it.

Regards,

Tony


8< -
#!/bin/bash

uarts=$(find /sys/class/tty/tty[SO]*/device/power/ -type d)
for uart in $uarts; do
echo 3000 > $uart/autosuspend_delay_ms 2>&1
done

uarts=$(find /sys/class/tty/tty[SO]*/power/ -type d 2>/dev/null)
for uart in $uarts; do
echo enabled > $uart/wakeup 2>&1
echo auto > $uart/control 2>&1
done

echo 1 > /sys/kernel/debug/pm_debug/enable_off_mode
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Laura Abbott]

On 12/23/2015 12:15 PM, Russell King - ARM Linux wrote:

On Wed, Dec 02, 2015 at 12:27:25PM -0800, Kees Cook wrote:

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.


Kees,

There is a subtle problem with the kernel memory permissions and the
DMA debugging.

DMA debugging checks whether we're trying to do DMA from the kernel
mappings (text, rodata, data etc).  It checks _text.._etext.  However,
when RODATA is enabled, we have about one section between _text and
_stext which are freed into the kernel's page pool, and then become
available for allocation and use for DMA.

This then causes the DMA debugging sanity check to fire.

So, I think I'll revert this change for the time being as it seems to
be causing many people problems, and having this enabled is creating
extra warnings when kernel debug options are enabled along with it.

Sorry.



in include/asm-generic/sections.h:

/*
 * Usage guidelines:
 * _text, _data: architecture specific, don't use them in arch-independent code
 * [_stext, _etext]: contains .text.* sections, may also contain .rodata.*
 *   and/or .init.* sections


So based on that comment it seems like the dma-debug should be checking for
_stext not _text since only _stext is guaranteed across all architectures.
I'll submit a patch to dma-debug.c if this seems appropriate or if you
haven't done so already.

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

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

[Russell King - ARM Linux]

On Wed, Dec 23, 2015 at 11:51:29AM -0800, Tony Lindgren wrote:
> Also all omap3 boards are now oopsing in Linux next if PM is enabled:

I'm not sure that's entirely true.  My LDP3430 works fine with this
change in place, and that has CONFIG_PM=y.  See my nightly build/boot
results, which includes an attempt to enter hibernation.  Remember
that last night's results are from my tree plus arm-soc's for-next.

Maybe there's some other change in linux-next which, when combined
with this change, is provoking it?

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Laura Abbott]

On 12/22/2015 02:37 AM, Geert Uytterhoeven wrote:

Hi Kees, Russell,

On Wed, Dec 2, 2015 at 9:27 PM, Kees Cook  wrote:

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 broke s2ram with shmobile_defconfig on r8a7791/koelsch:

 Freezing user space processes ... (elapsed 0.002 seconds) done.
 Freezing remaining freezable tasks ... (elapsed 0.003 seconds) done.
 PM: suspend of devices complete after 112.157 msecs
 PM: late suspend of devices complete after 1.605 msecs
 PM: noirq suspend of devices complete after 13.098 msecs
 Disabling non-boot CPUs ...
 s---[ end Kernel panic - not syncing: Attempted to kill the idle task!
 CPU0: stopping
 CPU: 0 PID: 2412 Comm: s2ram Tainted: G  D
4.4.0-rc6-3-g1bb20571dcf0edfc #470
 Hardware name: Generic R8A7791 (Flattened Device Tree)
 Backtrace:
 [] (dump_backtrace) from [] (show_stack+0x18/0x1c)
  r6: r5: r4: r3:80404000
 [] (show_stack) from [] (dump_stack+0x78/0x94)
 [] (dump_stack) from [] (handle_IPI+0xf4/0x19c)
  r4:c09313f0 r3:c09091ec
 [] (handle_IPI) from [] (gic_handle_irq+0x7c/0x98)
  r7:c0910b80 r6:ee1d5c30 r5:c0902754 r4:f0802000
 [] (gic_handle_irq) from [] (__irq_svc+0x54/0x70)
 Exception stack(0xee1d5c30 to 0xee1d5c78)
 5c20: c0955484 0002
 60070013
 5c40: c0942718 c093916c 0005 000f  
c0943088 ee1d5cd4
 5c60: ee1d5c08 ee1d5c80 c033fc20 c0158120 60070013 
  r8: r7:ee1d5c64 r6: r5:60070013 r4:c0158120 r3:c033fc20
 [] (console_unlock) from [] (vprintk_emit+0x448/0x4a4)
  r10:c09450a6 r9: r8:000e r7:0005 r6:0006 r5:c0932758
  r4:0001
 [] (vprintk_emit) from [] (vprintk_default+0x28/0x30)
  r10:c09055e0 r9:0001 r8:c09055e0 r7:0010 r6: r5:
  r4:0001
 [] (vprintk_default) from [] (printk+0x34/0x40)
 [] (printk) from [] (__cpu_die+0x34/0x78)
  r3:0003 r2:c0906808 r1:0001 r0:c0710af6
 [] (__cpu_die) from [] (_cpu_down+0x168/0x290)
  r4:0001 r3:0005
 [] (_cpu_down) from [] (disable_nonboot_cpus+0x70/0xf0)
  r10:0051 r9:c0932734 r8:c0902528 r7: r6:c090245c r5:c0931b40
  r4:0001
 [] (disable_nonboot_cpus) from []
(suspend_devices_and_enter+0x290/0x3f8)
  r8:c0714bb5 r7:eebac300 r6:0003 r5:c0932734 r4: r3:
 [] (suspend_devices_and_enter) from []
(pm_suspend+0xb4/0x1c8)
  r9:c093273c r8:c0714bb5 r7:eebac300 r6:0003 r5:c09576fc r4:
 [] (pm_suspend) from [] (state_store+0xb0/0xc4)
  r6:0004 r5:0003 r4:0003 r3:006d
 [] (state_store) from [] (kobj_attr_store+0x1c/0x28)
  r9:000cdc08 r8:ee1d5f80 r7:eebacb0c r6:eebacb00 r5:eebac300 r4:eebac300
 [] (kobj_attr_store) from [] (sysfs_kf_write+0x44/0x50)
 [] (sysfs_kf_write) from []
(kernfs_fop_write+0x13c/0x1a0)
  r4:0004 r3:c02223f4
 [] (kernfs_fop_write) from [] (__vfs_write+0x34/0xdc)
  r10: r9:ee1d4000 r8:c0106fa4 r7:0004 r6:ee1d5f80 r5:c02219a4
  r4:edf85d00
 [] (__vfs_write) from [] (vfs_write+0xb8/0x140)
  r7:ee1d5f80 r6:000cdc08 r5:edf85d00 r4:0004
 [] (vfs_write) from [] (SyS_write+0x50/0x90)
  r9:ee1d4000 r8:c0106fa4 r7:000cdc08 r6:0004 r5:edf85d00 r4:edf85d00
 [] (SyS_write) from [] (ret_fast_syscall+0x0/0x3c)

Before commit 1bb20571dcf0edfc ("ARM: 8470/1: mm: flip priority of
CONFIG_DEBUG_RODATA"):

 # CONFIG_ARM_KERNMEM_PERMS is not set

 Freezing user space processes ... (elapsed 0.001 seconds) done.
 Freezing remaining freezable tasks ... (elapsed 0.003 seconds) done.
 PM: suspend of devices complete after 112.163 msecs
 PM: late suspend of devices complete after 1.610 msecs
 PM: noirq suspend of devices complete after 13.109 msecs
 Disabling non-boot CPUs ...
 CPU1: shutdown

After the offending commit:

 CONFIG_DEBUG_RODATA=y
 CONFIG_DEBUG_ALIGN_RODATA=y

The "problem" is that DEBUG_RODATA now defaults to y on CPU_V7, so it gets
enabled for shmobile_defconfig. If I manually disable DEBUG_RODATA again,
s2ram does work.

The real problem is something else, though. I can trigger the same panic
without the offending commit by enabling:

 CONFIG_ARM_KERNMEM_PERMS=y
 CONFIG_DEBUG_RODATA=y

I never enabled those options before, so I have no idea if this is a recent
regression. I've just tried a few older versions: on v4.4-rc1 I see the same

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

[Geert Uytterhoeven]

Hi Kees, Russell,

On Wed, Dec 2, 2015 at 9:27 PM, Kees Cook  wrote:
> 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 broke s2ram with shmobile_defconfig on r8a7791/koelsch:

Freezing user space processes ... (elapsed 0.002 seconds) done.
Freezing remaining freezable tasks ... (elapsed 0.003 seconds) done.
PM: suspend of devices complete after 112.157 msecs
PM: late suspend of devices complete after 1.605 msecs
PM: noirq suspend of devices complete after 13.098 msecs
Disabling non-boot CPUs ...
s---[ end Kernel panic - not syncing: Attempted to kill the idle task!
CPU0: stopping
CPU: 0 PID: 2412 Comm: s2ram Tainted: G  D
4.4.0-rc6-3-g1bb20571dcf0edfc #470
Hardware name: Generic R8A7791 (Flattened Device Tree)
Backtrace:
[] (dump_backtrace) from [] (show_stack+0x18/0x1c)
 r6: r5: r4: r3:80404000
[] (show_stack) from [] (dump_stack+0x78/0x94)
[] (dump_stack) from [] (handle_IPI+0xf4/0x19c)
 r4:c09313f0 r3:c09091ec
[] (handle_IPI) from [] (gic_handle_irq+0x7c/0x98)
 r7:c0910b80 r6:ee1d5c30 r5:c0902754 r4:f0802000
[] (gic_handle_irq) from [] (__irq_svc+0x54/0x70)
Exception stack(0xee1d5c30 to 0xee1d5c78)
5c20: c0955484 0002
 60070013
5c40: c0942718 c093916c 0005 000f  
c0943088 ee1d5cd4
5c60: ee1d5c08 ee1d5c80 c033fc20 c0158120 60070013 
 r8: r7:ee1d5c64 r6: r5:60070013 r4:c0158120 r3:c033fc20
[] (console_unlock) from [] (vprintk_emit+0x448/0x4a4)
 r10:c09450a6 r9: r8:000e r7:0005 r6:0006 r5:c0932758
 r4:0001
[] (vprintk_emit) from [] (vprintk_default+0x28/0x30)
 r10:c09055e0 r9:0001 r8:c09055e0 r7:0010 r6: r5:
 r4:0001
[] (vprintk_default) from [] (printk+0x34/0x40)
[] (printk) from [] (__cpu_die+0x34/0x78)
 r3:0003 r2:c0906808 r1:0001 r0:c0710af6
[] (__cpu_die) from [] (_cpu_down+0x168/0x290)
 r4:0001 r3:0005
[] (_cpu_down) from [] (disable_nonboot_cpus+0x70/0xf0)
 r10:0051 r9:c0932734 r8:c0902528 r7: r6:c090245c r5:c0931b40
 r4:0001
[] (disable_nonboot_cpus) from []
(suspend_devices_and_enter+0x290/0x3f8)
 r8:c0714bb5 r7:eebac300 r6:0003 r5:c0932734 r4: r3:
[] (suspend_devices_and_enter) from []
(pm_suspend+0xb4/0x1c8)
 r9:c093273c r8:c0714bb5 r7:eebac300 r6:0003 r5:c09576fc r4:
[] (pm_suspend) from [] (state_store+0xb0/0xc4)
 r6:0004 r5:0003 r4:0003 r3:006d
[] (state_store) from [] (kobj_attr_store+0x1c/0x28)
 r9:000cdc08 r8:ee1d5f80 r7:eebacb0c r6:eebacb00 r5:eebac300 r4:eebac300
[] (kobj_attr_store) from [] (sysfs_kf_write+0x44/0x50)
[] (sysfs_kf_write) from []
(kernfs_fop_write+0x13c/0x1a0)
 r4:0004 r3:c02223f4
[] (kernfs_fop_write) from [] (__vfs_write+0x34/0xdc)
 r10: r9:ee1d4000 r8:c0106fa4 r7:0004 r6:ee1d5f80 r5:c02219a4
 r4:edf85d00
[] (__vfs_write) from [] (vfs_write+0xb8/0x140)
 r7:ee1d5f80 r6:000cdc08 r5:edf85d00 r4:0004
[] (vfs_write) from [] (SyS_write+0x50/0x90)
 r9:ee1d4000 r8:c0106fa4 r7:000cdc08 r6:0004 r5:edf85d00 r4:edf85d00
[] (SyS_write) from [] (ret_fast_syscall+0x0/0x3c)

Before commit 1bb20571dcf0edfc ("ARM: 8470/1: mm: flip priority of
CONFIG_DEBUG_RODATA"):

# CONFIG_ARM_KERNMEM_PERMS is not set

Freezing user space processes ... (elapsed 0.001 seconds) done.
Freezing remaining freezable tasks ... (elapsed 0.003 seconds) done.
PM: suspend of devices complete after 112.163 msecs
PM: late suspend of devices complete after 1.610 msecs
PM: noirq suspend of devices complete after 13.109 msecs
Disabling non-boot CPUs ...
CPU1: shutdown

After the offending commit:

CONFIG_DEBUG_RODATA=y
CONFIG_DEBUG_ALIGN_RODATA=y

The "problem" is that DEBUG_RODATA now defaults to y on CPU_V7, so it gets
enabled for shmobile_defconfig. If I manually disable DEBUG_RODATA again,
s2ram does work.

The real problem is something else, though. I can trigger the same panic
without the offending commit by enabling:

CONFIG_ARM_KERNMEM_PERMS=y
CONFIG_DEBUG_RODATA=y

I never enabled those options before, so I have no idea if this is a recent
regression. I've just tried a few older versions: on v4.4-rc1 I see the same
panic, on v4.3 (and v4.3.3) I don't see the panic, and the "CPU1: shutdown"
line, but the system doesn't wake 

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

[Laura Abbott]

On 12/22/2015 02:37 AM, Geert Uytterhoeven wrote:

Hi Kees, Russell,

On Wed, Dec 2, 2015 at 9:27 PM, Kees Cook  wrote:

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 broke s2ram with shmobile_defconfig on r8a7791/koelsch:

 Freezing user space processes ... (elapsed 0.002 seconds) done.
 Freezing remaining freezable tasks ... (elapsed 0.003 seconds) done.
 PM: suspend of devices complete after 112.157 msecs
 PM: late suspend of devices complete after 1.605 msecs
 PM: noirq suspend of devices complete after 13.098 msecs
 Disabling non-boot CPUs ...
 s---[ end Kernel panic - not syncing: Attempted to kill the idle task!
 CPU0: stopping
 CPU: 0 PID: 2412 Comm: s2ram Tainted: G  D
4.4.0-rc6-3-g1bb20571dcf0edfc #470
 Hardware name: Generic R8A7791 (Flattened Device Tree)
 Backtrace:
 [] (dump_backtrace) from [] (show_stack+0x18/0x1c)
  r6: r5: r4: r3:80404000
 [] (show_stack) from [] (dump_stack+0x78/0x94)
 [] (dump_stack) from [] (handle_IPI+0xf4/0x19c)
  r4:c09313f0 r3:c09091ec
 [] (handle_IPI) from [] (gic_handle_irq+0x7c/0x98)
  r7:c0910b80 r6:ee1d5c30 r5:c0902754 r4:f0802000
 [] (gic_handle_irq) from [] (__irq_svc+0x54/0x70)
 Exception stack(0xee1d5c30 to 0xee1d5c78)
 5c20: c0955484 0002
 60070013
 5c40: c0942718 c093916c 0005 000f  
c0943088 ee1d5cd4
 5c60: ee1d5c08 ee1d5c80 c033fc20 c0158120 60070013 
  r8: r7:ee1d5c64 r6: r5:60070013 r4:c0158120 r3:c033fc20
 [] (console_unlock) from [] (vprintk_emit+0x448/0x4a4)
  r10:c09450a6 r9: r8:000e r7:0005 r6:0006 r5:c0932758
  r4:0001
 [] (vprintk_emit) from [] (vprintk_default+0x28/0x30)
  r10:c09055e0 r9:0001 r8:c09055e0 r7:0010 r6: r5:
  r4:0001
 [] (vprintk_default) from [] (printk+0x34/0x40)
 [] (printk) from [] (__cpu_die+0x34/0x78)
  r3:0003 r2:c0906808 r1:0001 r0:c0710af6
 [] (__cpu_die) from [] (_cpu_down+0x168/0x290)
  r4:0001 r3:0005
 [] (_cpu_down) from [] (disable_nonboot_cpus+0x70/0xf0)
  r10:0051 r9:c0932734 r8:c0902528 r7: r6:c090245c r5:c0931b40
  r4:0001
 [] (disable_nonboot_cpus) from []
(suspend_devices_and_enter+0x290/0x3f8)
  r8:c0714bb5 r7:eebac300 r6:0003 r5:c0932734 r4: r3:
 [] (suspend_devices_and_enter) from []
(pm_suspend+0xb4/0x1c8)
  r9:c093273c r8:c0714bb5 r7:eebac300 r6:0003 r5:c09576fc r4:
 [] (pm_suspend) from [] (state_store+0xb0/0xc4)
  r6:0004 r5:0003 r4:0003 r3:006d
 [] (state_store) from [] (kobj_attr_store+0x1c/0x28)
  r9:000cdc08 r8:ee1d5f80 r7:eebacb0c r6:eebacb00 r5:eebac300 r4:eebac300
 [] (kobj_attr_store) from [] (sysfs_kf_write+0x44/0x50)
 [] (sysfs_kf_write) from []
(kernfs_fop_write+0x13c/0x1a0)
  r4:0004 r3:c02223f4
 [] (kernfs_fop_write) from [] (__vfs_write+0x34/0xdc)
  r10: r9:ee1d4000 r8:c0106fa4 r7:0004 r6:ee1d5f80 r5:c02219a4
  r4:edf85d00
 [] (__vfs_write) from [] (vfs_write+0xb8/0x140)
  r7:ee1d5f80 r6:000cdc08 r5:edf85d00 r4:0004
 [] (vfs_write) from [] (SyS_write+0x50/0x90)
  r9:ee1d4000 r8:c0106fa4 r7:000cdc08 r6:0004 r5:edf85d00 r4:edf85d00
 [] (SyS_write) from [] (ret_fast_syscall+0x0/0x3c)

Before commit 1bb20571dcf0edfc ("ARM: 8470/1: mm: flip priority of
CONFIG_DEBUG_RODATA"):

 # CONFIG_ARM_KERNMEM_PERMS is not set

 Freezing user space processes ... (elapsed 0.001 seconds) done.
 Freezing remaining freezable tasks ... (elapsed 0.003 seconds) done.
 PM: suspend of devices complete after 112.163 msecs
 PM: late suspend of devices complete after 1.610 msecs
 PM: noirq suspend of devices complete after 13.109 msecs
 Disabling non-boot CPUs ...
 CPU1: shutdown

After the offending commit:

 CONFIG_DEBUG_RODATA=y
 CONFIG_DEBUG_ALIGN_RODATA=y

The "problem" is that DEBUG_RODATA now defaults to y on CPU_V7, so it gets
enabled for shmobile_defconfig. If I manually disable DEBUG_RODATA again,
s2ram does work.

The real problem is something else, though. I can trigger the same panic
without the offending commit by enabling:

 CONFIG_ARM_KERNMEM_PERMS=y
 CONFIG_DEBUG_RODATA=y

I never enabled those options before, so I have no idea if this is a recent
regression. I've just tried a few older versions: on 

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

[Geert Uytterhoeven]

Hi Kees, Russell,

On Wed, Dec 2, 2015 at 9:27 PM, Kees Cook  wrote:
> 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 broke s2ram with shmobile_defconfig on r8a7791/koelsch:

Freezing user space processes ... (elapsed 0.002 seconds) done.
Freezing remaining freezable tasks ... (elapsed 0.003 seconds) done.
PM: suspend of devices complete after 112.157 msecs
PM: late suspend of devices complete after 1.605 msecs
PM: noirq suspend of devices complete after 13.098 msecs
Disabling non-boot CPUs ...
s---[ end Kernel panic - not syncing: Attempted to kill the idle task!
CPU0: stopping
CPU: 0 PID: 2412 Comm: s2ram Tainted: G  D
4.4.0-rc6-3-g1bb20571dcf0edfc #470
Hardware name: Generic R8A7791 (Flattened Device Tree)
Backtrace:
[] (dump_backtrace) from [] (show_stack+0x18/0x1c)
 r6: r5: r4: r3:80404000
[] (show_stack) from [] (dump_stack+0x78/0x94)
[] (dump_stack) from [] (handle_IPI+0xf4/0x19c)
 r4:c09313f0 r3:c09091ec
[] (handle_IPI) from [] (gic_handle_irq+0x7c/0x98)
 r7:c0910b80 r6:ee1d5c30 r5:c0902754 r4:f0802000
[] (gic_handle_irq) from [] (__irq_svc+0x54/0x70)
Exception stack(0xee1d5c30 to 0xee1d5c78)
5c20: c0955484 0002
 60070013
5c40: c0942718 c093916c 0005 000f  
c0943088 ee1d5cd4
5c60: ee1d5c08 ee1d5c80 c033fc20 c0158120 60070013 
 r8: r7:ee1d5c64 r6: r5:60070013 r4:c0158120 r3:c033fc20
[] (console_unlock) from [] (vprintk_emit+0x448/0x4a4)
 r10:c09450a6 r9: r8:000e r7:0005 r6:0006 r5:c0932758
 r4:0001
[] (vprintk_emit) from [] (vprintk_default+0x28/0x30)
 r10:c09055e0 r9:0001 r8:c09055e0 r7:0010 r6: r5:
 r4:0001
[] (vprintk_default) from [] (printk+0x34/0x40)
[] (printk) from [] (__cpu_die+0x34/0x78)
 r3:0003 r2:c0906808 r1:0001 r0:c0710af6
[] (__cpu_die) from [] (_cpu_down+0x168/0x290)
 r4:0001 r3:0005
[] (_cpu_down) from [] (disable_nonboot_cpus+0x70/0xf0)
 r10:0051 r9:c0932734 r8:c0902528 r7: r6:c090245c r5:c0931b40
 r4:0001
[] (disable_nonboot_cpus) from []
(suspend_devices_and_enter+0x290/0x3f8)
 r8:c0714bb5 r7:eebac300 r6:0003 r5:c0932734 r4: r3:
[] (suspend_devices_and_enter) from []
(pm_suspend+0xb4/0x1c8)
 r9:c093273c r8:c0714bb5 r7:eebac300 r6:0003 r5:c09576fc r4:
[] (pm_suspend) from [] (state_store+0xb0/0xc4)
 r6:0004 r5:0003 r4:0003 r3:006d
[] (state_store) from [] (kobj_attr_store+0x1c/0x28)
 r9:000cdc08 r8:ee1d5f80 r7:eebacb0c r6:eebacb00 r5:eebac300 r4:eebac300
[] (kobj_attr_store) from [] (sysfs_kf_write+0x44/0x50)
[] (sysfs_kf_write) from []
(kernfs_fop_write+0x13c/0x1a0)
 r4:0004 r3:c02223f4
[] (kernfs_fop_write) from [] (__vfs_write+0x34/0xdc)
 r10: r9:ee1d4000 r8:c0106fa4 r7:0004 r6:ee1d5f80 r5:c02219a4
 r4:edf85d00
[] (__vfs_write) from [] (vfs_write+0xb8/0x140)
 r7:ee1d5f80 r6:000cdc08 r5:edf85d00 r4:0004
[] (vfs_write) from [] (SyS_write+0x50/0x90)
 r9:ee1d4000 r8:c0106fa4 r7:000cdc08 r6:0004 r5:edf85d00 r4:edf85d00
[] (SyS_write) from [] (ret_fast_syscall+0x0/0x3c)

Before commit 1bb20571dcf0edfc ("ARM: 8470/1: mm: flip priority of
CONFIG_DEBUG_RODATA"):

# CONFIG_ARM_KERNMEM_PERMS is not set

Freezing user space processes ... (elapsed 0.001 seconds) done.
Freezing remaining freezable tasks ... (elapsed 0.003 seconds) done.
PM: suspend of devices complete after 112.163 msecs
PM: late suspend of devices complete after 1.610 msecs
PM: noirq suspend of devices complete after 13.109 msecs
Disabling non-boot CPUs ...
CPU1: shutdown

After the offending commit:

CONFIG_DEBUG_RODATA=y
CONFIG_DEBUG_ALIGN_RODATA=y

The "problem" is that DEBUG_RODATA now defaults to y on CPU_V7, so it gets
enabled for shmobile_defconfig. If I manually disable DEBUG_RODATA again,
s2ram does work.

The real problem is something else, though. I can trigger the same panic
without the offending commit by enabling:

CONFIG_ARM_KERNMEM_PERMS=y
CONFIG_DEBUG_RODATA=y

I never enabled those options before, so I have no idea if this is a recent
regression. I've just tried a few older versions: on v4.4-rc1 I see the same
panic, on v4.3 (and v4.3.3) I don't see the panic, and the "CPU1: shutdown"
line, but 

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

[Laura Abbott]

On 12/02/2015 12:27 PM, Kees Cook wrote:

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 adds human readable names to the sections so I could more easily
debug my typos, and makes CONFIG_DEBUG_RODATA default "y" for CPU_V7.

Results in /sys/kernel/debug/kernel_page_tables for each config state:

  # CONFIG_DEBUG_RODATA is not set
  # CONFIG_DEBUG_ALIGN_RODATA is not set

---[ Kernel Mapping ]---
0x8000-0x8090   9M RW x  SHD
0x8090-0xa000 503M RW NX SHD

  CONFIG_DEBUG_RODATA=y
  CONFIG_DEBUG_ALIGN_RODATA=y

---[ Kernel Mapping ]---
0x8000-0x8010   1M RW NX SHD
0x8010-0x8070   6M ro x  SHD
0x8070-0x80a0   3M ro NX SHD
0x80a0-0xa000 502M RW NX SHD

  CONFIG_DEBUG_RODATA=y
  # CONFIG_DEBUG_ALIGN_RODATA is not set

---[ Kernel Mapping ]---
0x8000-0x8010   1M RW NX SHD
0x8010-0x80a0   9M ro x  SHD
0x80a0-0xa000 502M RW NX SHD

Signed-off-by: Kees Cook 
---


Reviewed-by: Laura Abbott 

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

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

[Kees Cook]

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 adds human readable names to the sections so I could more easily
debug my typos, and makes CONFIG_DEBUG_RODATA default "y" for CPU_V7.

Results in /sys/kernel/debug/kernel_page_tables for each config state:

 # CONFIG_DEBUG_RODATA is not set
 # CONFIG_DEBUG_ALIGN_RODATA is not set

---[ Kernel Mapping ]---
0x8000-0x8090   9M RW x  SHD
0x8090-0xa000 503M RW NX SHD

 CONFIG_DEBUG_RODATA=y
 CONFIG_DEBUG_ALIGN_RODATA=y

---[ Kernel Mapping ]---
0x8000-0x8010   1M RW NX SHD
0x8010-0x8070   6M ro x  SHD
0x8070-0x80a0   3M ro NX SHD
0x80a0-0xa000 502M RW NX SHD

 CONFIG_DEBUG_RODATA=y
 # CONFIG_DEBUG_ALIGN_RODATA is not set

---[ Kernel Mapping ]---
0x8000-0x8010   1M RW NX SHD
0x8010-0x80a0   9M ro x  SHD
0x80a0-0xa000 502M RW NX SHD

Signed-off-by: Kees Cook 
---
Depends on 8464/1 "Update all mm structures with section adjustments"
---
 arch/arm/kernel/vmlinux.lds.S | 10 +-
 arch/arm/mm/Kconfig   | 34 ++
 arch/arm/mm/init.c| 19 ++-
 3 files changed, 33 insertions(+), 30 deletions(-)

diff --git a/arch/arm/kernel/vmlinux.lds.S b/arch/arm/kernel/vmlinux.lds.S
index 8b60fde5ce48..a6e395c53a48 100644
--- a/arch/arm/kernel/vmlinux.lds.S
+++ b/arch/arm/kernel/vmlinux.lds.S
@@ -8,7 +8,7 @@
 #include 
 #include 
 #include 
-#ifdef CONFIG_ARM_KERNMEM_PERMS
+#ifdef CONFIG_DEBUG_RODATA
 #include 
 #endif
 
@@ -94,7 +94,7 @@ SECTIONS
HEAD_TEXT
}
 
-#ifdef CONFIG_ARM_KERNMEM_PERMS
+#ifdef CONFIG_DEBUG_RODATA
. = ALIGN(1

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

[Kees Cook]

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 adds human readable names to the sections so I could more easily
debug my typos, and makes CONFIG_DEBUG_RODATA default "y" for CPU_V7.

Results in /sys/kernel/debug/kernel_page_tables for each config state:

 # CONFIG_DEBUG_RODATA is not set
 # CONFIG_DEBUG_ALIGN_RODATA is not set

---[ Kernel Mapping ]---
0x8000-0x8090   9M RW x  SHD
0x8090-0xa000 503M RW NX SHD

 CONFIG_DEBUG_RODATA=y
 CONFIG_DEBUG_ALIGN_RODATA=y

---[ Kernel Mapping ]---
0x8000-0x8010   1M RW NX SHD
0x8010-0x8070   6M ro x  SHD
0x8070-0x80a0   3M ro NX SHD
0x80a0-0xa000 502M RW NX SHD

 CONFIG_DEBUG_RODATA=y
 # CONFIG_DEBUG_ALIGN_RODATA is not set

---[ Kernel Mapping ]---
0x8000-0x8010   1M RW NX SHD
0x8010-0x80a0   9M ro x  SHD
0x80a0-0xa000 502M RW NX SHD

Signed-off-by: Kees Cook 
---
Depends on 8464/1 "Update all mm structures with section adjustments"
---
 arch/arm/kernel/vmlinux.lds.S | 10 +-
 arch/arm/mm/Kconfig   | 34 ++
 arch/arm/mm/init.c| 19 ++-
 3 files changed, 33 insertions(+), 30 deletions(-)

diff --git a/arch/arm/kernel/vmlinux.lds.S b/arch/arm/kernel/vmlinux.lds.S
index 8b60fde5ce48..a6e395c53a48 100644
--- a/arch/arm/kernel/vmlinux.lds.S
+++ b/arch/arm/kernel/vmlinux.lds.S
@@ -8,7 +8,7 @@
 #include 
 #include 
 #include 
-#ifdef CONFIG_ARM_KERNMEM_PERMS
+#ifdef CONFIG_DEBUG_RODATA
 #include 
 #endif
 
@@ -94,7 +94,7 @@ SECTIONS
HEAD_TEXT
}
 
-#ifdef CONFIG_ARM_KERNMEM_PERMS
+#ifdef CONFIG_DEBUG_RODATA
. = ALIGN(1<

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

[Laura Abbott]

On 12/02/2015 12:27 PM, Kees Cook wrote:

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 adds human readable names to the sections so I could more easily
debug my typos, and makes CONFIG_DEBUG_RODATA default "y" for CPU_V7.

Results in /sys/kernel/debug/kernel_page_tables for each config state:

  # CONFIG_DEBUG_RODATA is not set
  # CONFIG_DEBUG_ALIGN_RODATA is not set

---[ Kernel Mapping ]---
0x8000-0x8090   9M RW x  SHD
0x8090-0xa000 503M RW NX SHD

  CONFIG_DEBUG_RODATA=y
  CONFIG_DEBUG_ALIGN_RODATA=y

---[ Kernel Mapping ]---
0x8000-0x8010   1M RW NX SHD
0x8010-0x8070   6M ro x  SHD
0x8070-0x80a0   3M ro NX SHD
0x80a0-0xa000 502M RW NX SHD

  CONFIG_DEBUG_RODATA=y
  # CONFIG_DEBUG_ALIGN_RODATA is not set

---[ Kernel Mapping ]---
0x8000-0x8010   1M RW NX SHD
0x8010-0x80a0   9M ro x  SHD
0x80a0-0xa000 502M RW NX SHD

Signed-off-by: Kees Cook 
---


Reviewed-by: Laura Abbott 

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