arm32 insecure W+X mapping

[Tim Harvey]

On Mon, Sep 20, 2021 at 2:13 PM Russell King (Oracle)
<linux at armlinux.org.uk> wrote:
>
> On Mon, Sep 20, 2021 at 01:56:51PM -0700, Tim Harvey wrote:
> > On Mon, Sep 20, 2021 at 9:22 AM Russell King (Oracle)
> > <linux at armlinux.org.uk> wrote:
> > >
> > > On Wed, Sep 15, 2021 at 06:44:56AM -0300, Fabio Estevam wrote:
> > > > Not sure if this is related or not to the following behavior that I am seeing.
> > > >
> > > > On 5.15-rc1 I see the following on an imx6dl based board:
> > > >
> > > > [    0.123336] imx6q_suspend_init: failed to find ocram device!
> > >
> > > Looking at the platforms I currently have, two imx6q which booted 5.13
> > > do not have this problem, but one imx6dl that booted 5.14 does seem to
> > > spit out this message.
> > >
> > > What I do notice is that in the 5.14 case, /proc/iomem reports that the
> > > ocram device does exist:
> > >
> > > 00900000-0091ffff : 900000.sram sram at 900000
> > >
> > > so I'm suspecting an init ordering issue.
> > >
> > > It looks on the face of it to be a regression between 5.13 and 5.14.
> > > I'm guessing that the sram device isn't being probed early enough.
> > > Maybe some of the initialisation/device model debug options can
> > > identify what changed?
> > >
> >
> > Here's what I see on both imx6dl and imx6q with both CONFIG_DEBUG_WX
> > and CONFIG_SUSPEND enabled:
> > 5.13: 'Checked W+X mappings: FAILED, 1 W+X pages found' on both imx6q and imx6dl
> > 5.14: No W+X failure on either board.... so something different for sure
> > 5.15-rc2: same as 5.14
> >
> > So my results differ from yours but showed that something has been
> > fixed vs regressed. I'll bisect and see if I can figure out when my
> > original issue I reported here went away.
>
> I'm not sure we are disagreeing. I don't have CONFIG_DEBUG_WX enabled,
> but in 5.13, I see in /sys/kernel/debug/kernel_page_tables:
>
> 0xf087d000-0xf087e000           4K KERNEL      RW x  SHD MEM/BUFFERABLE/WC
>
> and /proc/vmallocinfo has:
>
> 0xf087d000-0xf087f000    8192 imx6_pm_common_init+0x13c/0x390 phys=0x00900000 ioremap
>
> So this will give a W+X failure.
>
> Under 5.14, there is no mapping for this RAM in kernel_page_tables nor
> vmallocinfo - which is not surprising because imx6_pm_common_init()
> said it failed to find the ocram, and it only gets one shot at it.
> So there won't be a W+X failure.
>
> In other words, we are in complete agreement.
>

Ok - makes sense.

I bisected this to cc8870bf4c3a ("ARM: imx6q: drop
of_platform_default_populate() from init_machine").

After that patch we get:
[    0.133082] imx6q_suspend_init: failed to find ocram device!

and no longer see the W+X failure.

Fabio, I suspect this is the regression that you are hitting regarding
suspend and that this needs to be reverted.

That will still leave the W+X issue needing to be fixed at some point.

Tim