All of lore.kernel.org
 help / color / mirror / Atom feed
* arm32 insecure W+X mapping
@ 2021-08-19 17:19 Tim Harvey
  2021-08-19 21:28 ` Russell King (Oracle)
  0 siblings, 1 reply; 20+ messages in thread
From: Tim Harvey @ 2021-08-19 17:19 UTC (permalink / raw)
  To: Linux ARM Mailing List

Greetings,

Since commit a8e53c151fe7 "(ARM: 8737/1: mm: dump: add checking for
writable and executable)" I've been seeing the following appear on my
arm32 kernel:

arm/mm: Found insecure W+X mapping at address 0xf087d000
...
Checked W+X mappings: FAILED, 1 W+X pages found

As I haven't seen others report this I assume it's something unique to
my kernel configuration. How do I debug what is causing the insecure
page?

Best regards,

Tim

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: arm32 insecure W+X mapping
  2021-08-19 17:19 arm32 insecure W+X mapping Tim Harvey
@ 2021-08-19 21:28 ` Russell King (Oracle)
  2021-08-19 23:59   ` Tim Harvey
  0 siblings, 1 reply; 20+ messages in thread
From: Russell King (Oracle) @ 2021-08-19 21:28 UTC (permalink / raw)
  To: Tim Harvey; +Cc: Linux ARM Mailing List

On Thu, Aug 19, 2021 at 10:19:46AM -0700, Tim Harvey wrote:
> Greetings,
> 
> Since commit a8e53c151fe7 "(ARM: 8737/1: mm: dump: add checking for
> writable and executable)" I've been seeing the following appear on my
> arm32 kernel:
> 
> arm/mm: Found insecure W+X mapping at address 0xf087d000
> ...
> Checked W+X mappings: FAILED, 1 W+X pages found
> 
> As I haven't seen others report this I assume it's something unique to
> my kernel configuration. How do I debug what is causing the insecure
> page?

If you check /proc/vmallocinfo, it should tell you the physical
address that was mapped there, and the function that created the
mapping. That should give enough clues to track it down.

Thanks.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: arm32 insecure W+X mapping
  2021-08-19 21:28 ` Russell King (Oracle)
@ 2021-08-19 23:59   ` Tim Harvey
  2021-08-20  0:16     ` Russell King (Oracle)
  0 siblings, 1 reply; 20+ messages in thread
From: Tim Harvey @ 2021-08-19 23:59 UTC (permalink / raw)
  To: Russell King (Oracle); +Cc: Linux ARM Mailing List

On Thu, Aug 19, 2021 at 2:28 PM Russell King (Oracle)
<linux@armlinux.org.uk> wrote:
>
> On Thu, Aug 19, 2021 at 10:19:46AM -0700, Tim Harvey wrote:
> > Greetings,
> >
> > Since commit a8e53c151fe7 "(ARM: 8737/1: mm: dump: add checking for
> > writable and executable)" I've been seeing the following appear on my
> > arm32 kernel:
> >
> > arm/mm: Found insecure W+X mapping at address 0xf087d000
> > ...
> > Checked W+X mappings: FAILED, 1 W+X pages found
> >
> > As I haven't seen others report this I assume it's something unique to
> > my kernel configuration. How do I debug what is causing the insecure
> > page?
>
> If you check /proc/vmallocinfo, it should tell you the physical
> address that was mapped there, and the function that created the
> mapping. That should give enough clues to track it down.
>

Russell,

Thanks for the tip!

# dmesg | grep insecure
[   13.219582] arm/mm: Found insecure W+X mapping at address 0xf087d000
# cat /proc/vmallocinfo | grep 0xf0
0x5f3045dd-0xf0020e05   20480 imx6_pm_get_base+0x64/0x98 phys=0x020e0000 ioremap
0xf0020e05-0x6e748217    8192 dma_common_contiguous_remap+0x88/0xa4 dma-coherent
0x127639d7-0x334ee291    4096 iotable_init+0x0/0xf0 phys=0x00a00000 ioremap

So this is saying its dma-coherent mapped from dma_common_continguous_remap?

# cat /proc/vmallocinfo
0x572091e4-0x27690de5   20480 of_iomap+0x44/0x68 phys=0x020d8000 ioremap
0x27690de5-0x35897f01    8192 of_iomap+0x44/0x68 phys=0x00a01000 ioremap
0xe3186ca4-0x0f1ef5e3   20480 of_iomap+0x44/0x68 phys=0x020dc000 ioremap
0x0f1ef5e3-0x5ece7ccc    8192 l2x0_of_init+0x78/0x26c phys=0x00a02000 ioremap
0xb5c85079-0xc2ca2734   20480 of_iomap+0x44/0x68 phys=0x020c4000 ioremap
0xc2ca2734-0xaf3c42de    8192 of_iomap+0x44/0x68 phys=0x020c8000 ioremap
0x28e036be-0xd5974946   20480 of_iomap+0x44/0x68 phys=0x020c4000 ioremap
0xeae42964-0xc4e615a6   20480 of_iomap+0x44/0x68 phys=0x02098000 ioremap
0x6a6bab5f-0x3ecf3e8c    8192 bpf_prog_alloc_no_stats+0x2c/0x118 pages=1 vmalloc
0x3ecf3e8c-0xbb5cf07d  266240 dma_common_contiguous_remap+0x88/0xa4 dma-coherent
0xbb5cf07d-0x1a6cd05a    8192 gen_pool_add_owner+0x34/0x94 pages=1 vmalloc
0x1a6cd05a-0xcafd679a    8192 of_syscon_register+0xb8/0x2a0
phys=0x020c8000 ioremap
0xcafd679a-0xab606572    8192 __devm_ioremap+0x94/0xa4 phys=0x020c9000 ioremap
0xab606572-0xd42260ec    8192 __devm_ioremap+0x94/0xa4 phys=0x020ca000 ioremap
0xd42260ec-0xcbe84677    8192 gen_pool_add_owner+0x34/0x94 pages=1 vmalloc
0xcbe84677-0x235c7c16   20480 of_iomap+0x44/0x68 phys=0x021b0000 ioremap
0x235c7c16-0xb235d3f3    8192 imx6_pm_common_init+0x118/0x36c
phys=0x00900000 ioremap
0x47e7e130-0x808ca2d4  266240 __devm_ioremap+0x50/0xa4 phys=0x00900000 ioremap
0x808ca2d4-0xfccba85b    8192 imx6_pm_get_base+0x64/0x98 phys=0x00a02000 ioremap
0x800f4671-0xc7775acd   20480 imx6_pm_get_base+0x64/0x98 phys=0x021b0000 ioremap
0xc7775acd-0xa724d9e0    8192 of_syscon_register+0xb8/0x2a0
phys=0x020e0000 ioremap
0xb762f02e-0xed6991ca   20480 imx6_pm_get_base+0x64/0x98 phys=0x020d8000 ioremap
0xed6991ca-0xdbb588fa    8192 dma_common_contiguous_remap+0x88/0xa4 dma-coherent
0x5f3045dd-0xf0020e05   20480 imx6_pm_get_base+0x64/0x98 phys=0x020e0000 ioremap
0xf0020e05-0x6e748217    8192 dma_common_contiguous_remap+0x88/0xa4 dma-coherent
0x0b51e410-0x3d898417   20480 imx6_pm_get_base+0x64/0x98 phys=0x020dc000 ioremap
0x3d898417-0x86992438    8192 __devm_ioremap+0x94/0xa4 phys=0x02600000 ioremap
0x6464407c-0x60718db5   20480 __devm_ioremap+0x94/0xa4 phys=0x020e0000 ioremap
0x4c7be824-0xfe1fc1f2   20480 __devm_ioremap+0x94/0xa4 phys=0x0209c000 ioremap
0xfe1fc1f2-0x46954edf    8192 __devm_ioremap+0x94/0xa4 phys=0x02608000 ioremap
0x53446305-0x435a58b4   20480 __devm_ioremap+0x94/0xa4 phys=0x020a0000 ioremap
0x435a58b4-0x2e1fc59d    8192 __devm_ioremap+0x94/0xa4 phys=0x02630000 ioremap
0x3f2c2f34-0x01a2f43c   20480 __devm_ioremap+0x94/0xa4 phys=0x020a4000 ioremap
0x01a2f43c-0x6b20a97a    8192 __devm_ioremap+0x94/0xa4 phys=0x02638000 ioremap
0x6fd6457c-0xe0eb3463   20480 __devm_ioremap+0x94/0xa4 phys=0x020a8000 ioremap
0xe0eb3463-0xec4965e5    8192 __devm_ioremap+0x94/0xa4 phys=0x02620000 ioremap
0x5c03cdf7-0x3b1b3493   20480 __devm_ioremap+0x94/0xa4 phys=0x020ac000 ioremap
0x3b1b3493-0xad9aee67    8192 __devm_ioremap+0x94/0xa4 phys=0x02668000 ioremap
0x92feb1f5-0x7414f542   20480 __devm_ioremap+0x94/0xa4 phys=0x020b0000 ioremap
0x7414f542-0x7a40d77f    8192 __devm_ioremap+0x94/0xa4 phys=0x02640000 ioremap
0x8ee37216-0xbe006eb2   20480 __devm_ioremap+0x94/0xa4 phys=0x020b4000 ioremap
0x29a6ecde-0x80a7a60b   12288 __devm_ioremap+0x94/0xa4 phys=0x00110000 ioremap
0x80a7a60b-0x3db02e14    8192 __devm_ioremap+0x94/0xa4 phys=0x02648000 ioremap
0x60036855-0x1e6802e0   20480 __devm_ioremap+0x94/0xa4 phys=0x021a0000 ioremap
0x1e6802e0-0x62fd3e57    8192 __devm_ioremap+0x94/0xa4 phys=0x02658000 ioremap
0xabcb6908-0xa070b2ec   20480 __devm_ioremap+0x94/0xa4 phys=0x021a4000 ioremap
0xa070b2ec-0xe713ec73    8192 __devm_ioremap+0x94/0xa4 phys=0x02780000 ioremap
0x1d8444e1-0xcac4726c   20480 __devm_ioremap+0x94/0xa4 phys=0x021a8000 ioremap
0xcac4726c-0x8025cc0f    8192 __devm_ioremap+0x94/0xa4 phys=0x02660000 ioremap
0x1ae47ba3-0xf8c7f1ca   20480 __devm_ioremap+0x94/0xa4 phys=0x021d8000 ioremap
0xf8c7f1ca-0x32e09fa4    8192 __devm_ioremap+0x94/0xa4 phys=0x02740000 ioremap
0x4d10befe-0x60b4c1e9   20480 __devm_ioremap+0x94/0xa4 phys=0x01ffc000 ioremap
0x60b4c1e9-0xb3a54244    8192 __devm_ioremap+0x94/0xa4 phys=0x02650000 ioremap
0xe04d1c20-0x97be33d0   20480 __devm_ioremap+0x94/0xa4 phys=0x020ec000 ioremap
0x97be33d0-0xc1afe24c    8192 __devm_ioremap+0x94/0xa4 phys=0x02a00000 ioremap
0xac1caf35-0x7ceb30f1   20480 of_syscon_register+0xb8/0x2a0
phys=0x021bc000 ioremap
0x7ceb30f1-0x245e06af    8192 __devm_ioremap+0x94/0xa4 phys=0x02a08000 ioremap
0x6c5425e7-0x84bc25cc   20480 __devm_ioremap+0x94/0xa4 phys=0x020dc000 ioremap
0x84bc25cc-0x595056c5    8192 __devm_ioremap+0x94/0xa4 phys=0x02a30000 ioremap
0x074d8ed7-0x2e4d1a53   20480 __devm_ioremap+0x94/0xa4 phys=0x02020000 ioremap
0x2e4d1a53-0x95ed192f    8192 __devm_ioremap+0x94/0xa4 phys=0x02a38000 ioremap
0x19e0356d-0x45e14fed   20480 __devm_ioremap+0x94/0xa4 phys=0x021e8000 ioremap
0x45e14fed-0xe690f152    8192 __devm_ioremap+0x94/0xa4 phys=0x02a20000 ioremap
0x991fa501-0x9fdabf5a   20480 __devm_ioremap+0x94/0xa4 phys=0x021f4000 ioremap
0x9fdabf5a-0x3e67dae9    8192 __devm_ioremap+0x94/0xa4 phys=0x02a68000 ioremap
0x82e937d0-0x0811797e   40960 __devm_ioremap+0x94/0xa4 phys=0x00120000 ioremap
0x0811797e-0x923f8a88    8192 __devm_ioremap+0x94/0xa4 phys=0x02a40000 ioremap
0x923f8a88-0x206017e5   20480 __devm_ioremap+0x94/0xa4 phys=0x00130000 ioremap
0x206017e5-0x6c990a7b    8192 __devm_ioremap+0x94/0xa4 phys=0x02a48000 ioremap
0x99673e2c-0x2cac9053   20480 __devm_ioremap+0x94/0xa4 phys=0x00134000 ioremap
0x2cac9053-0x85ae7df8    8192 __devm_ioremap+0x94/0xa4 phys=0x02a58000 ioremap
0x85ae7df8-0x4405ccb4    8192 __devm_ioremap+0x94/0xa4 phys=0x02b80000 ioremap
0x4405ccb4-0xae8efb1a    8192 __devm_ioremap+0x94/0xa4 phys=0x02a60000 ioremap
0x126bbd24-0x2249ff6f  528384 devm_pci_remap_cfgspace+0x3c/0x74
phys=0x01f00000 ioremap
0x2249ff6f-0x8c2e304c  135168 dma_common_contiguous_remap+0x88/0xa4 dma-coherent
0x8c2e304c-0x0bf3a28c    8192 dma_common_contiguous_remap+0x88/0xa4 dma-coherent
0x0bf3a28c-0x96e17d3f   20480 __devm_ioremap+0x94/0xa4 phys=0x02204000 ioremap
0x96e17d3f-0xa4daba8c  528384 dma_common_contiguous_remap+0x88/0xa4 dma-coherent
0xa4daba8c-0xe6185530    8192 __devm_ioremap+0x94/0xa4 phys=0x02b40000 ioremap
0xe6185530-0x821c3b4a    8192 __devm_ioremap+0x94/0xa4 phys=0x02a50000 ioremap
0xbd3e3c5d-0x597081d3  135168 __devm_ioremap+0x94/0xa4 phys=0x02700000 ioremap
0x0f8ddd13-0x32e4fd76   12288 __devm_ioremap+0x94/0xa4 phys=0x00112000 ioremap
0x32e4fd76-0x811b112c    8192 __pci_enable_msix_range+0x1b4/0x50c
phys=0x01420000 ioremap
0xce8aec4a-0xb2dd309c   69632 __devm_ioremap+0x94/0xa4 phys=0x02760000 ioremap
0xb2dd309c-0x5ff80254   81920 pcpu_create_chunk+0x14c/0x290 pages=19 vmalloc
0x6325b825-0xd6880a57    8192 __devm_ioremap+0x94/0xa4 phys=0x02184000 ioremap
0xd6880a57-0x01fdf853  135168 __devm_ioremap+0x94/0xa4 phys=0x02b00000 ioremap
0xfbfae5e4-0x34f66182   12288 __devm_ioremap+0x94/0xa4 phys=0x00114000 ioremap
0x34f66182-0x9759721e    8192 __devm_ioremap+0x94/0xa4 phys=0x02184000 ioremap
0xff9a433f-0x6ffcb3fc   69632 __devm_ioremap+0x94/0xa4 phys=0x02b60000 ioremap
0x6ffcb3fc-0x925370c6 4153344 dma_common_contiguous_remap+0x88/0xa4 dma-coherent
0x89e10860-0x935fedfd   20480 __devm_ioremap+0x94/0xa4 phys=0x02200000 ioremap
0x935fedfd-0xb3e1eed1   98304 dma_common_contiguous_remap+0x88/0xa4 dma-coherent
0xb3e1eed1-0xd19ae2f1   36864 iscsi_target_init_module+0xb4/0x234
pages=8 vmalloc
0xd19ae2f1-0x4ef92f29   20480 dma_common_contiguous_remap+0x88/0xa4 dma-coherent
0x0e67a0eb-0x32add077   20480 __devm_ioremap+0x94/0xa4 phys=0x0200c000 ioremap
0x32add077-0xf2ae7966    8192 dma_common_contiguous_remap+0x88/0xa4 dma-coherent
0x24b26351-0x10c489ec   20480 __devm_ioremap+0x94/0xa4 phys=0x02188000 ioremap
0x10c489ec-0x99550a81  135168 dma_common_contiguous_remap+0x88/0xa4 dma-coherent
0x99550a81-0xb8546101   36864 dma_common_contiguous_remap+0x88/0xa4 dma-coherent
0xb757667d-0x00d14870   20480 __devm_ioremap+0x94/0xa4 phys=0x021e4000 ioremap
0x00d14870-0x4997051a    8192 dma_common_contiguous_remap+0x88/0xa4 dma-coherent
0xcd1bbc96-0x5470c56e   20480 __devm_ioremap+0x94/0xa4 phys=0x020c0000 ioremap
0x5470c56e-0x5041fe43    8192 dma_common_contiguous_remap+0x88/0xa4 dma-coherent
0x27c17eec-0x5f300c54   20480 __devm_ioremap+0x94/0xa4 phys=0x02198000 ioremap
0x5f300c54-0x779e324f    8192 __devm_ioremap+0x94/0xa4 phys=0x02184000 ioremap
0x71eda903-0x08c271b0  135168 igb_probe+0x150/0x10a4 phys=0x01400000 ioremap
0x08c271b0-0xaad09678    8192 dma_common_contiguous_remap+0x88/0xa4 dma-coherent
0x20320ae4-0x995de6c0   20480 __devm_ioremap+0x94/0xa4 phys=0x02034000 ioremap
0x995de6c0-0x53fe07bc    8192 dma_common_contiguous_remap+0x88/0xa4 dma-coherent
0x66a2a7f0-0x144dcde1   20480 __devm_ioremap+0x94/0xa4 phys=0x02028000 ioremap
0x144dcde1-0x28fcbfb5    8192 dma_common_contiguous_remap+0x88/0xa4 dma-coherent
0xd4d631e6-0x89b9dbd5   20480 __devm_ioremap+0x94/0xa4 phys=0x0202c000 ioremap
0x89b9dbd5-0xba573900   16384 n_tty_open+0x10/0x9c pages=3 vmalloc
0xf1af7427-0x2dd3f3b0  528384 dma_common_contiguous_remap+0x88/0xa4 dma-coherent
0x7ea79487-0xb5aa9a4a  528384 dma_common_contiguous_remap+0x88/0xa4 dma-coherent
0xb5aa9a4a-0x38706b86 1294336 zstd_comp_init+0x58/0xb0 pages=315 vmalloc
0x38706b86-0x2073eebb  163840 zstd_decomp_init+0x14/0x54 pages=39 vmalloc
0x2073eebb-0x0e3cf5f0  274432 deflate_comp_init+0x20/0x90 pages=66 vmalloc
0x0e3cf5f0-0x03c153c7   49152 deflate_decomp_init+0x14/0x58 pages=11 vmalloc
0x32a3b715-0x45627fc0  249856 __devm_ioremap+0x94/0xa4 phys=0x02040000 ioremap
0x45627fc0-0x8420dc4c  212992 dma_common_contiguous_remap+0x88/0xa4 dma-coherent
0x8420dc4c-0x0268f3a7  528384 dma_common_contiguous_remap+0x88/0xa4 dma-coherent
0x127639d7-0x334ee291    4096 iotable_init+0x0/0xf0 phys=0x00a00000 ioremap
0x9569c0e1-0x413f89f0 2097152 pci_reserve_io+0x0/0x30 ioremap
0x1fa52fb4-0xe4568750  311296 pcpu_get_vm_areas+0x0/0x10c0 vmalloc
0xe4568750-0x2633c5e5  311296 pcpu_get_vm_areas+0x0/0x10c0 vmalloc
0x8276ef58-0x572091e4   16384 unpurged vm_area
0xd5974946-0xe417a989    8192 unpurged vm_area
0xc4e615a6-0x6a6bab5f    8192 unpurged vm_area
0x60718db5-0x4c7be824 15609856 unpurged vm_area
0x821c3b4a-0xbd3e3c5d   73728 unpurged vm_area
0x597081d3-0x0f8ddd13   36864 unpurged vm_area
0x5ff80254-0x6325b825   36864 unpurged vm_area
0x01fdf853-0xfbfae5e4   36864 unpurged vm_area
0x925370c6-0x208e0e7e  442368 unpurged vm_area
0xe1ca9db2-0xf1af7427  249856 unpurged vm_area
0x2dd3f3b0-0x7ea79487   36864 unpurged vm_area

Thanks,

Tim

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: arm32 insecure W+X mapping
  2021-08-19 23:59   ` Tim Harvey
@ 2021-08-20  0:16     ` Russell King (Oracle)
  2021-08-20 16:06       ` Tim Harvey
  0 siblings, 1 reply; 20+ messages in thread
From: Russell King (Oracle) @ 2021-08-20  0:16 UTC (permalink / raw)
  To: Tim Harvey; +Cc: Linux ARM Mailing List

On Thu, Aug 19, 2021 at 04:59:15PM -0700, Tim Harvey wrote:
> On Thu, Aug 19, 2021 at 2:28 PM Russell King (Oracle)
> <linux@armlinux.org.uk> wrote:
> >
> > On Thu, Aug 19, 2021 at 10:19:46AM -0700, Tim Harvey wrote:
> > > Greetings,
> > >
> > > Since commit a8e53c151fe7 "(ARM: 8737/1: mm: dump: add checking for
> > > writable and executable)" I've been seeing the following appear on my
> > > arm32 kernel:
> > >
> > > arm/mm: Found insecure W+X mapping at address 0xf087d000
> > > ...
> > > Checked W+X mappings: FAILED, 1 W+X pages found
> > >
> > > As I haven't seen others report this I assume it's something unique to
> > > my kernel configuration. How do I debug what is causing the insecure
> > > page?
> >
> > If you check /proc/vmallocinfo, it should tell you the physical
> > address that was mapped there, and the function that created the
> > mapping. That should give enough clues to track it down.
> >
> 
> Russell,
> 
> Thanks for the tip!
> 
> # dmesg | grep insecure
> [   13.219582] arm/mm: Found insecure W+X mapping at address 0xf087d000
> # cat /proc/vmallocinfo | grep 0xf0
> 0x5f3045dd-0xf0020e05   20480 imx6_pm_get_base+0x64/0x98 phys=0x020e0000 ioremap
> 0xf0020e05-0x6e748217    8192 dma_common_contiguous_remap+0x88/0xa4 dma-coherent
> 0x127639d7-0x334ee291    4096 iotable_init+0x0/0xf0 phys=0x00a00000 ioremap

Oh... the kernel's %p pointer munging (for security reasons) is
affecting your ability to debug your problem. Assuming this is a
recent kernel, you can disable this by passing "no_hash_pointers"
on the kernel command line. You should then see real addresses (and
a big fat message at boot time about it.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: arm32 insecure W+X mapping
  2021-08-20  0:16     ` Russell King (Oracle)
@ 2021-08-20 16:06       ` Tim Harvey
  2021-08-20 17:48         ` Robin Murphy
  0 siblings, 1 reply; 20+ messages in thread
From: Tim Harvey @ 2021-08-20 16:06 UTC (permalink / raw)
  To: Russell King (Oracle); +Cc: Linux ARM Mailing List

On Thu, Aug 19, 2021 at 5:16 PM Russell King (Oracle)
<linux@armlinux.org.uk> wrote:
>
> On Thu, Aug 19, 2021 at 04:59:15PM -0700, Tim Harvey wrote:
> > On Thu, Aug 19, 2021 at 2:28 PM Russell King (Oracle)
> > <linux@armlinux.org.uk> wrote:
> > >
> > > On Thu, Aug 19, 2021 at 10:19:46AM -0700, Tim Harvey wrote:
> > > > Greetings,
> > > >
> > > > Since commit a8e53c151fe7 "(ARM: 8737/1: mm: dump: add checking for
> > > > writable and executable)" I've been seeing the following appear on my
> > > > arm32 kernel:
> > > >
> > > > arm/mm: Found insecure W+X mapping at address 0xf087d000
> > > > ...
> > > > Checked W+X mappings: FAILED, 1 W+X pages found
> > > >
> > > > As I haven't seen others report this I assume it's something unique to
> > > > my kernel configuration. How do I debug what is causing the insecure
> > > > page?
> > >
> > > If you check /proc/vmallocinfo, it should tell you the physical
> > > address that was mapped there, and the function that created the
> > > mapping. That should give enough clues to track it down.
> > >
> >
> > Russell,
> >
> > Thanks for the tip!
> >
> > # dmesg | grep insecure
> > [   13.219582] arm/mm: Found insecure W+X mapping at address 0xf087d000
> > # cat /proc/vmallocinfo | grep 0xf0
> > 0x5f3045dd-0xf0020e05   20480 imx6_pm_get_base+0x64/0x98 phys=0x020e0000 ioremap
> > 0xf0020e05-0x6e748217    8192 dma_common_contiguous_remap+0x88/0xa4 dma-coherent
> > 0x127639d7-0x334ee291    4096 iotable_init+0x0/0xf0 phys=0x00a00000 ioremap
>
> Oh... the kernel's %p pointer munging (for security reasons) is
> affecting your ability to debug your problem. Assuming this is a
> recent kernel, you can disable this by passing "no_hash_pointers"
> on the kernel command line. You should then see real addresses (and
> a big fat message at boot time about it.
>

I'm using 5.13 and when I pass in 'no_hash_pointers' I do indeed see
the huge warning but I get similar results that I can't make sense of:
# uname -r
5.13.0-00009-g8beacec9a060
# cat /proc/cmdline
console=ttymxc1,115200 no_hash_pointers
# dmesg | grep insecure
[   13.309537] arm/mm: Found insecure W+X mapping at address 0xf087d000
# cat /proc/vmallocinfo | grep 0xf0
0xf02c73a9-0xfa933595   20480 __devm_ioremap+0x94/0xa4 phys=0x0202c000 ioremap
0xc02cb795-0x054951d9    4096 iotable_init+0x0/0xf0 phys=0x00a00000 ioremap
# cat /proc/vmallocinfo
0xbe008562-0x5576ab44   20480 of_iomap+0x44/0x68 phys=0x020d8000 ioremap
0x5576ab44-0xb255df29    8192 of_iomap+0x44/0x68 phys=0x00a01000 ioremap
0x46b8335b-0x447c6b02   20480 of_iomap+0x44/0x68 phys=0x020dc000 ioremap
0x447c6b02-0x7527802c    8192 l2x0_of_init+0x78/0x26c phys=0x00a02000 ioremap
0xee30b5de-0x9e0d6dbd   20480 of_iomap+0x44/0x68 phys=0x020c4000 ioremap
0x9e0d6dbd-0xf62147bb    8192 of_iomap+0x44/0x68 phys=0x020c8000 ioremap
0xfe3688a4-0xecfce701   20480 of_iomap+0x44/0x68 phys=0x020c4000 ioremap
0x0d7d7401-0xce35bdb8   20480 of_iomap+0x44/0x68 phys=0x02098000 ioremap
0xd0da9915-0xa147e0b3    8192 bpf_prog_alloc_no_stats+0x2c/0x118 pages=1 vmalloc
0xa147e0b3-0xb043f532  266240 dma_common_contiguous_remap+0x88/0xa4 dma-coherent
0xb043f532-0x7f372e98    8192 gen_pool_add_owner+0x34/0x94 pages=1 vmalloc
0x7f372e98-0x22c0f7fa    8192 of_syscon_register+0xb8/0x2a0
phys=0x020c8000 ioremap
0x22c0f7fa-0xbc80b65b    8192 __devm_ioremap+0x94/0xa4 phys=0x020c9000 ioremap
0xbc80b65b-0x5737939a    8192 __devm_ioremap+0x94/0xa4 phys=0x020ca000 ioremap
0x5737939a-0xfaac3f4b    8192 gen_pool_add_owner+0x34/0x94 pages=1 vmalloc
0xfaac3f4b-0x3400434f   20480 of_iomap+0x44/0x68 phys=0x021b0000 ioremap
0x3400434f-0x4b5b39be    8192 imx6_pm_common_init+0x118/0x36c
phys=0x00900000 ioremap
0xfa6109c5-0x8220d86a  266240 __devm_ioremap+0x50/0xa4 phys=0x00900000 ioremap
0x8220d86a-0xbb32fa78    8192 imx6_pm_get_base+0x64/0x98 phys=0x00a02000 ioremap
0xe37ddad7-0x94023f64   20480 imx6_pm_get_base+0x64/0x98 phys=0x021b0000 ioremap
0x94023f64-0x032e50a3    8192 of_syscon_register+0xb8/0x2a0
phys=0x020e0000 ioremap
0xd41722d0-0x69a3231e   20480 imx6_pm_get_base+0x64/0x98 phys=0x020d8000 ioremap
0x69a3231e-0x6dc29018    8192 dma_common_contiguous_remap+0x88/0xa4 dma-coherent
0x327a8342-0x78efb8e0   20480 imx6_pm_get_base+0x64/0x98 phys=0x020e0000 ioremap
0x78efb8e0-0xe6178284    8192 dma_common_contiguous_remap+0x88/0xa4 dma-coherent
0x76f38a9b-0x34af82ac   20480 imx6_pm_get_base+0x64/0x98 phys=0x020dc000 ioremap
0x34af82ac-0x81d03489    8192 __devm_ioremap+0x94/0xa4 phys=0x02600000 ioremap
0x63fe0abd-0x6b04db7d   20480 __devm_ioremap+0x94/0xa4 phys=0x020e0000 ioremap
0xb849bd1c-0xc46ae71e   20480 __devm_ioremap+0x94/0xa4 phys=0x0209c000 ioremap
0xc46ae71e-0x1eb811b8    8192 __devm_ioremap+0x94/0xa4 phys=0x02608000 ioremap
0x2c687987-0xbae166ed   20480 __devm_ioremap+0x94/0xa4 phys=0x020a0000 ioremap
0xbae166ed-0xb27fac72    8192 __devm_ioremap+0x94/0xa4 phys=0x02630000 ioremap
0x0868e824-0xa08b93b8   20480 __devm_ioremap+0x94/0xa4 phys=0x020a4000 ioremap
0xa08b93b8-0x73e79d37    8192 __devm_ioremap+0x94/0xa4 phys=0x02638000 ioremap
0x3ff71a53-0x1664550e   20480 __devm_ioremap+0x94/0xa4 phys=0x020a8000 ioremap
0x1664550e-0xdffb9edc    8192 __devm_ioremap+0x94/0xa4 phys=0x02620000 ioremap
0x1d0f2f08-0xb32e296b   20480 __devm_ioremap+0x94/0xa4 phys=0x020ac000 ioremap
0xb32e296b-0x7062006c    8192 __devm_ioremap+0x94/0xa4 phys=0x02668000 ioremap
0xff2f5a70-0xff7ff60a   20480 __devm_ioremap+0x94/0xa4 phys=0x020b0000 ioremap
0xff7ff60a-0x8779d9bc    8192 __devm_ioremap+0x94/0xa4 phys=0x02640000 ioremap
0xccc5d4a4-0xbbd8184e   20480 __devm_ioremap+0x94/0xa4 phys=0x020b4000 ioremap
0xf3211f15-0xdf4e4390   12288 __devm_ioremap+0x94/0xa4 phys=0x00110000 ioremap
0xdf4e4390-0x8b969f88    8192 __devm_ioremap+0x94/0xa4 phys=0x02648000 ioremap
0x67d4c705-0x2844e8ae   20480 __devm_ioremap+0x94/0xa4 phys=0x021a0000 ioremap
0x2844e8ae-0xe969daac    8192 __devm_ioremap+0x94/0xa4 phys=0x02658000 ioremap
0x6c51de7f-0x13285901   20480 __devm_ioremap+0x94/0xa4 phys=0x021a4000 ioremap
0x13285901-0xcf2d44dd    8192 __devm_ioremap+0x94/0xa4 phys=0x02780000 ioremap
0x632c016d-0x81fc4149   20480 __devm_ioremap+0x94/0xa4 phys=0x021a8000 ioremap
0x81fc4149-0xd005970a    8192 __devm_ioremap+0x94/0xa4 phys=0x02660000 ioremap
0xacd62b34-0x2369ad7d   20480 __devm_ioremap+0x94/0xa4 phys=0x021d8000 ioremap
0x2369ad7d-0x6c218545    8192 __devm_ioremap+0x94/0xa4 phys=0x02740000 ioremap
0xd8caee3b-0x8f7b3eae   20480 __devm_ioremap+0x94/0xa4 phys=0x01ffc000 ioremap
0x8f7b3eae-0x7754f3e6    8192 __devm_ioremap+0x94/0xa4 phys=0x02650000 ioremap
0xcf739a9c-0x86505b25   20480 __devm_ioremap+0x94/0xa4 phys=0x020ec000 ioremap
0x86505b25-0x4419339d    8192 __devm_ioremap+0x94/0xa4 phys=0x02a00000 ioremap
0x38550150-0xee5ad30c   20480 of_syscon_register+0xb8/0x2a0
phys=0x021bc000 ioremap
0xee5ad30c-0x73467058    8192 __devm_ioremap+0x94/0xa4 phys=0x02a08000 ioremap
0x7659aedb-0xd37bf098   20480 __devm_ioremap+0x94/0xa4 phys=0x020dc000 ioremap
0xd37bf098-0x6b62199d    8192 __devm_ioremap+0x94/0xa4 phys=0x02a30000 ioremap
0xe2fcb2be-0x83ac2ff4   20480 __devm_ioremap+0x94/0xa4 phys=0x02020000 ioremap
0x83ac2ff4-0x498e66da    8192 __devm_ioremap+0x94/0xa4 phys=0x02a38000 ioremap
0xda200768-0x9519b5b7   20480 __devm_ioremap+0x94/0xa4 phys=0x021e8000 ioremap
0x9519b5b7-0xd8066315    8192 __devm_ioremap+0x94/0xa4 phys=0x02a20000 ioremap
0x327c6cd3-0xb09836e5   20480 __devm_ioremap+0x94/0xa4 phys=0x021f4000 ioremap
0xb09836e5-0x2ee61e13    8192 __devm_ioremap+0x94/0xa4 phys=0x02a68000 ioremap
0x28a28e71-0xfb74b75d   40960 __devm_ioremap+0x94/0xa4 phys=0x00120000 ioremap
0xfb74b75d-0x94731aa5    8192 __devm_ioremap+0x94/0xa4 phys=0x02a40000 ioremap
0x94731aa5-0x9ed95f4b   20480 __devm_ioremap+0x94/0xa4 phys=0x00130000 ioremap
0x9ed95f4b-0xb6679e93    8192 __devm_ioremap+0x94/0xa4 phys=0x02a48000 ioremap
0xd2083a49-0xd15b1ee5   20480 __devm_ioremap+0x94/0xa4 phys=0x00134000 ioremap
0xd15b1ee5-0xb873e80d    8192 __devm_ioremap+0x94/0xa4 phys=0x02a58000 ioremap
0xb873e80d-0xad853c5f    8192 __devm_ioremap+0x94/0xa4 phys=0x02b80000 ioremap
0xad853c5f-0x727a169b    8192 __devm_ioremap+0x94/0xa4 phys=0x02a60000 ioremap
0x79bcf223-0xd8778c7f  528384 devm_pci_remap_cfgspace+0x3c/0x74
phys=0x01f00000 ioremap
0xd8778c7f-0xcd8f995b  135168 dma_common_contiguous_remap+0x88/0xa4 dma-coherent
0xcd8f995b-0x0e93c50d    8192 dma_common_contiguous_remap+0x88/0xa4 dma-coherent
0x0e93c50d-0x35d018fd   20480 __devm_ioremap+0x94/0xa4 phys=0x02204000 ioremap
0x35d018fd-0x30dd9119  528384 dma_common_contiguous_remap+0x88/0xa4 dma-coherent
0x30dd9119-0x1d49a1b3    8192 __devm_ioremap+0x94/0xa4 phys=0x02b40000 ioremap
0x1d49a1b3-0xe202a461    8192 __devm_ioremap+0x94/0xa4 phys=0x02a50000 ioremap
0x3c5f9898-0x7c998da8  135168 __devm_ioremap+0x94/0xa4 phys=0x02700000 ioremap
0x0be6bff2-0xe617431b   12288 __devm_ioremap+0x94/0xa4 phys=0x00112000 ioremap
0xe617431b-0x1894871f    8192 __pci_enable_msix_range+0x1b4/0x50c
phys=0x01420000 ioremap
0xcc3e24ea-0x24fc33d0   69632 __devm_ioremap+0x94/0xa4 phys=0x02760000 ioremap
0x24fc33d0-0x2ad2fe2c   81920 pcpu_create_chunk+0x14c/0x290 pages=19 vmalloc
0x064e8962-0x041a1631    8192 __devm_ioremap+0x94/0xa4 phys=0x02184000 ioremap
0x041a1631-0xa78f78b0  135168 __devm_ioremap+0x94/0xa4 phys=0x02b00000 ioremap
0x482eea6f-0xa04223bd   12288 __devm_ioremap+0x94/0xa4 phys=0x00114000 ioremap
0xa04223bd-0x47cd64d8    8192 __devm_ioremap+0x94/0xa4 phys=0x02184000 ioremap
0x496ff4b8-0x1b8cd27f   69632 __devm_ioremap+0x94/0xa4 phys=0x02b60000 ioremap
0x1b8cd27f-0x9a03a792 1576960 dma_common_contiguous_remap+0x88/0xa4 dma-coherent
0x9e844161-0x46bbc5c3    8192 dma_common_contiguous_remap+0x88/0xa4 dma-coherent
0x46bbc5c3-0x061f37bb   20480 __devm_ioremap+0x94/0xa4 phys=0x02200000 ioremap
0x061f37bb-0x099e44f8   98304 dma_common_contiguous_remap+0x88/0xa4 dma-coherent
0x099e44f8-0x5a73428f   36864 iscsi_target_init_module+0xb4/0x234
pages=8 vmalloc
0x5a73428f-0x6b24094e   20480 dma_common_contiguous_remap+0x88/0xa4 dma-coherent
0x8763af88-0xc279660f   20480 __devm_ioremap+0x94/0xa4 phys=0x0200c000 ioremap
0xc279660f-0x0746510e    8192 dma_common_contiguous_remap+0x88/0xa4 dma-coherent
0xc42e58a5-0x9bb92a15   20480 __devm_ioremap+0x94/0xa4 phys=0x02188000 ioremap
0x9bb92a15-0xbffbc968  135168 dma_common_contiguous_remap+0x88/0xa4 dma-coherent
0xbffbc968-0xc3135661   36864 dma_common_contiguous_remap+0x88/0xa4 dma-coherent
0x7f8906cc-0x57602490   20480 __devm_ioremap+0x94/0xa4 phys=0x021e4000 ioremap
0x57602490-0x32a0cd25    8192 dma_common_contiguous_remap+0x88/0xa4 dma-coherent
0x32a0cd25-0xccf592e4    8192 __devm_ioremap+0x94/0xa4 phys=0x02184000 ioremap
0xccf592e4-0xc3d5117e    8192 dma_common_contiguous_remap+0x88/0xa4 dma-coherent
0xd80eccd6-0x1eccdd8b  135168 igb_probe+0x150/0x10a4 phys=0x01400000 ioremap
0x1eccdd8b-0x360f1603    8192 dma_common_contiguous_remap+0x88/0xa4 dma-coherent
0x32fecfc9-0x71e47aa2   20480 __devm_ioremap+0x94/0xa4 phys=0x020c0000 ioremap
0x71e47aa2-0x5098c2fb    8192 dma_common_contiguous_remap+0x88/0xa4 dma-coherent
0xaf379216-0x24330e7c   20480 __devm_ioremap+0x94/0xa4 phys=0x02198000 ioremap
0x3dd54ba7-0x2392a17a   20480 __devm_ioremap+0x94/0xa4 phys=0x02034000 ioremap
0x2392a17a-0x1e11712d   16384 n_tty_open+0x10/0x9c pages=3 vmalloc
0x300b1fb4-0x33dba900   20480 __devm_ioremap+0x94/0xa4 phys=0x02028000 ioremap
0xf02c73a9-0xfa933595   20480 __devm_ioremap+0x94/0xa4 phys=0x0202c000 ioremap
0xbe5c4daa-0x6af5bd9c  528384 dma_common_contiguous_remap+0x88/0xa4 dma-coherent
0x6af5bd9c-0x9ea7250e  528384 dma_common_contiguous_remap+0x88/0xa4 dma-coherent
0x9ea7250e-0x74bbeefe 1294336 zstd_comp_init+0x58/0xb0 pages=315 vmalloc
0x74bbeefe-0x591c7299  163840 zstd_decomp_init+0x14/0x54 pages=39 vmalloc
0x591c7299-0x27154f89  274432 deflate_comp_init+0x20/0x90 pages=66 vmalloc
0x27154f89-0x3978b460   49152 deflate_decomp_init+0x14/0x58 pages=11 vmalloc
0x3978b460-0x99da8daa  212992 dma_common_contiguous_remap+0x88/0xa4 dma-coherent
0xe9a5ec5f-0xb0e53888  249856 __devm_ioremap+0x94/0xa4 phys=0x02040000 ioremap
0xb0e53888-0xc24dd16d  528384 dma_common_contiguous_remap+0x88/0xa4 dma-coherent
0xc02cb795-0x054951d9    4096 iotable_init+0x0/0xf0 phys=0x00a00000 ioremap
0x32815c21-0x48bd192d 2097152 pci_reserve_io+0x0/0x30 ioremap
0xba73986b-0x4f91845f  311296 pcpu_get_vm_areas+0x0/0x10c0 vmalloc
0x4f91845f-0x86cbfbfa  311296 pcpu_get_vm_areas+0x0/0x10c0 vmalloc
0x17d9341e-0xbe008562   16384 unpurged vm_area
0xecfce701-0xd35ab9b8    8192 unpurged vm_area
0xce35bdb8-0xd0da9915    8192 unpurged vm_area
0x6b04db7d-0xb849bd1c 15609856 unpurged vm_area
0xe202a461-0x3c5f9898   73728 unpurged vm_area
0x7c998da8-0x0be6bff2   36864 unpurged vm_area
0x2ad2fe2c-0x064e8962   36864 unpurged vm_area
0xa78f78b0-0x482eea6f   36864 unpurged vm_area
0x9a03a792-0x9e844161  442368 unpurged vm_area
0x92d57223-0xd09758da  249856 unpurged vm_area
0xfa933595-0xbe5c4daa   36864 unpurged vm_area

Thanks for your help!

Tim

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: arm32 insecure W+X mapping
  2021-08-20 16:06       ` Tim Harvey
@ 2021-08-20 17:48         ` Robin Murphy
  2021-08-20 18:41           ` Tim Harvey
  0 siblings, 1 reply; 20+ messages in thread
From: Robin Murphy @ 2021-08-20 17:48 UTC (permalink / raw)
  To: Tim Harvey, Russell King (Oracle); +Cc: Linux ARM Mailing List

On 2021-08-20 17:06, Tim Harvey wrote:
> On Thu, Aug 19, 2021 at 5:16 PM Russell King (Oracle)
> <linux@armlinux.org.uk> wrote:
>>
>> On Thu, Aug 19, 2021 at 04:59:15PM -0700, Tim Harvey wrote:
>>> On Thu, Aug 19, 2021 at 2:28 PM Russell King (Oracle)
>>> <linux@armlinux.org.uk> wrote:
>>>>
>>>> On Thu, Aug 19, 2021 at 10:19:46AM -0700, Tim Harvey wrote:
>>>>> Greetings,
>>>>>
>>>>> Since commit a8e53c151fe7 "(ARM: 8737/1: mm: dump: add checking for
>>>>> writable and executable)" I've been seeing the following appear on my
>>>>> arm32 kernel:
>>>>>
>>>>> arm/mm: Found insecure W+X mapping at address 0xf087d000
>>>>> ...
>>>>> Checked W+X mappings: FAILED, 1 W+X pages found
>>>>>
>>>>> As I haven't seen others report this I assume it's something unique to
>>>>> my kernel configuration. How do I debug what is causing the insecure
>>>>> page?
>>>>
>>>> If you check /proc/vmallocinfo, it should tell you the physical
>>>> address that was mapped there, and the function that created the
>>>> mapping. That should give enough clues to track it down.
>>>>
>>>
>>> Russell,
>>>
>>> Thanks for the tip!
>>>
>>> # dmesg | grep insecure
>>> [   13.219582] arm/mm: Found insecure W+X mapping at address 0xf087d000
>>> # cat /proc/vmallocinfo | grep 0xf0
>>> 0x5f3045dd-0xf0020e05   20480 imx6_pm_get_base+0x64/0x98 phys=0x020e0000 ioremap
>>> 0xf0020e05-0x6e748217    8192 dma_common_contiguous_remap+0x88/0xa4 dma-coherent
>>> 0x127639d7-0x334ee291    4096 iotable_init+0x0/0xf0 phys=0x00a00000 ioremap
>>
>> Oh... the kernel's %p pointer munging (for security reasons) is
>> affecting your ability to debug your problem. Assuming this is a
>> recent kernel, you can disable this by passing "no_hash_pointers"
>> on the kernel command line. You should then see real addresses (and
>> a big fat message at boot time about it.
>>
> 
> I'm using 5.13 and when I pass in 'no_hash_pointers' I do indeed see
> the huge warning but I get similar results that I can't make sense of:

Pointer hashing always trips me up too, so I thought I'd chuck my 
curiosity into the ring...

Between the vmallocinfo and printk code, it looks like you need to set 
/proc/sys/kptr_restrict to 1 and be root (or have CAP_SYSLOG privilege) 
to get non-hashed addresses here. Because having only one way to confuse 
debugging would be far too easy, I guess :/

Robin.

> # uname -r
> 5.13.0-00009-g8beacec9a060
> # cat /proc/cmdline
> console=ttymxc1,115200 no_hash_pointers
> # dmesg | grep insecure
> [   13.309537] arm/mm: Found insecure W+X mapping at address 0xf087d000
> # cat /proc/vmallocinfo | grep 0xf0
> 0xf02c73a9-0xfa933595   20480 __devm_ioremap+0x94/0xa4 phys=0x0202c000 ioremap
> 0xc02cb795-0x054951d9    4096 iotable_init+0x0/0xf0 phys=0x00a00000 ioremap
> # cat /proc/vmallocinfo
> 0xbe008562-0x5576ab44   20480 of_iomap+0x44/0x68 phys=0x020d8000 ioremap
> 0x5576ab44-0xb255df29    8192 of_iomap+0x44/0x68 phys=0x00a01000 ioremap
> 0x46b8335b-0x447c6b02   20480 of_iomap+0x44/0x68 phys=0x020dc000 ioremap
> 0x447c6b02-0x7527802c    8192 l2x0_of_init+0x78/0x26c phys=0x00a02000 ioremap
> 0xee30b5de-0x9e0d6dbd   20480 of_iomap+0x44/0x68 phys=0x020c4000 ioremap
> 0x9e0d6dbd-0xf62147bb    8192 of_iomap+0x44/0x68 phys=0x020c8000 ioremap
> 0xfe3688a4-0xecfce701   20480 of_iomap+0x44/0x68 phys=0x020c4000 ioremap
> 0x0d7d7401-0xce35bdb8   20480 of_iomap+0x44/0x68 phys=0x02098000 ioremap
> 0xd0da9915-0xa147e0b3    8192 bpf_prog_alloc_no_stats+0x2c/0x118 pages=1 vmalloc
> 0xa147e0b3-0xb043f532  266240 dma_common_contiguous_remap+0x88/0xa4 dma-coherent
> 0xb043f532-0x7f372e98    8192 gen_pool_add_owner+0x34/0x94 pages=1 vmalloc
> 0x7f372e98-0x22c0f7fa    8192 of_syscon_register+0xb8/0x2a0
> phys=0x020c8000 ioremap
> 0x22c0f7fa-0xbc80b65b    8192 __devm_ioremap+0x94/0xa4 phys=0x020c9000 ioremap
> 0xbc80b65b-0x5737939a    8192 __devm_ioremap+0x94/0xa4 phys=0x020ca000 ioremap
> 0x5737939a-0xfaac3f4b    8192 gen_pool_add_owner+0x34/0x94 pages=1 vmalloc
> 0xfaac3f4b-0x3400434f   20480 of_iomap+0x44/0x68 phys=0x021b0000 ioremap
> 0x3400434f-0x4b5b39be    8192 imx6_pm_common_init+0x118/0x36c
> phys=0x00900000 ioremap
> 0xfa6109c5-0x8220d86a  266240 __devm_ioremap+0x50/0xa4 phys=0x00900000 ioremap
> 0x8220d86a-0xbb32fa78    8192 imx6_pm_get_base+0x64/0x98 phys=0x00a02000 ioremap
> 0xe37ddad7-0x94023f64   20480 imx6_pm_get_base+0x64/0x98 phys=0x021b0000 ioremap
> 0x94023f64-0x032e50a3    8192 of_syscon_register+0xb8/0x2a0
> phys=0x020e0000 ioremap
> 0xd41722d0-0x69a3231e   20480 imx6_pm_get_base+0x64/0x98 phys=0x020d8000 ioremap
> 0x69a3231e-0x6dc29018    8192 dma_common_contiguous_remap+0x88/0xa4 dma-coherent
> 0x327a8342-0x78efb8e0   20480 imx6_pm_get_base+0x64/0x98 phys=0x020e0000 ioremap
> 0x78efb8e0-0xe6178284    8192 dma_common_contiguous_remap+0x88/0xa4 dma-coherent
> 0x76f38a9b-0x34af82ac   20480 imx6_pm_get_base+0x64/0x98 phys=0x020dc000 ioremap
> 0x34af82ac-0x81d03489    8192 __devm_ioremap+0x94/0xa4 phys=0x02600000 ioremap
> 0x63fe0abd-0x6b04db7d   20480 __devm_ioremap+0x94/0xa4 phys=0x020e0000 ioremap
> 0xb849bd1c-0xc46ae71e   20480 __devm_ioremap+0x94/0xa4 phys=0x0209c000 ioremap
> 0xc46ae71e-0x1eb811b8    8192 __devm_ioremap+0x94/0xa4 phys=0x02608000 ioremap
> 0x2c687987-0xbae166ed   20480 __devm_ioremap+0x94/0xa4 phys=0x020a0000 ioremap
> 0xbae166ed-0xb27fac72    8192 __devm_ioremap+0x94/0xa4 phys=0x02630000 ioremap
> 0x0868e824-0xa08b93b8   20480 __devm_ioremap+0x94/0xa4 phys=0x020a4000 ioremap
> 0xa08b93b8-0x73e79d37    8192 __devm_ioremap+0x94/0xa4 phys=0x02638000 ioremap
> 0x3ff71a53-0x1664550e   20480 __devm_ioremap+0x94/0xa4 phys=0x020a8000 ioremap
> 0x1664550e-0xdffb9edc    8192 __devm_ioremap+0x94/0xa4 phys=0x02620000 ioremap
> 0x1d0f2f08-0xb32e296b   20480 __devm_ioremap+0x94/0xa4 phys=0x020ac000 ioremap
> 0xb32e296b-0x7062006c    8192 __devm_ioremap+0x94/0xa4 phys=0x02668000 ioremap
> 0xff2f5a70-0xff7ff60a   20480 __devm_ioremap+0x94/0xa4 phys=0x020b0000 ioremap
> 0xff7ff60a-0x8779d9bc    8192 __devm_ioremap+0x94/0xa4 phys=0x02640000 ioremap
> 0xccc5d4a4-0xbbd8184e   20480 __devm_ioremap+0x94/0xa4 phys=0x020b4000 ioremap
> 0xf3211f15-0xdf4e4390   12288 __devm_ioremap+0x94/0xa4 phys=0x00110000 ioremap
> 0xdf4e4390-0x8b969f88    8192 __devm_ioremap+0x94/0xa4 phys=0x02648000 ioremap
> 0x67d4c705-0x2844e8ae   20480 __devm_ioremap+0x94/0xa4 phys=0x021a0000 ioremap
> 0x2844e8ae-0xe969daac    8192 __devm_ioremap+0x94/0xa4 phys=0x02658000 ioremap
> 0x6c51de7f-0x13285901   20480 __devm_ioremap+0x94/0xa4 phys=0x021a4000 ioremap
> 0x13285901-0xcf2d44dd    8192 __devm_ioremap+0x94/0xa4 phys=0x02780000 ioremap
> 0x632c016d-0x81fc4149   20480 __devm_ioremap+0x94/0xa4 phys=0x021a8000 ioremap
> 0x81fc4149-0xd005970a    8192 __devm_ioremap+0x94/0xa4 phys=0x02660000 ioremap
> 0xacd62b34-0x2369ad7d   20480 __devm_ioremap+0x94/0xa4 phys=0x021d8000 ioremap
> 0x2369ad7d-0x6c218545    8192 __devm_ioremap+0x94/0xa4 phys=0x02740000 ioremap
> 0xd8caee3b-0x8f7b3eae   20480 __devm_ioremap+0x94/0xa4 phys=0x01ffc000 ioremap
> 0x8f7b3eae-0x7754f3e6    8192 __devm_ioremap+0x94/0xa4 phys=0x02650000 ioremap
> 0xcf739a9c-0x86505b25   20480 __devm_ioremap+0x94/0xa4 phys=0x020ec000 ioremap
> 0x86505b25-0x4419339d    8192 __devm_ioremap+0x94/0xa4 phys=0x02a00000 ioremap
> 0x38550150-0xee5ad30c   20480 of_syscon_register+0xb8/0x2a0
> phys=0x021bc000 ioremap
> 0xee5ad30c-0x73467058    8192 __devm_ioremap+0x94/0xa4 phys=0x02a08000 ioremap
> 0x7659aedb-0xd37bf098   20480 __devm_ioremap+0x94/0xa4 phys=0x020dc000 ioremap
> 0xd37bf098-0x6b62199d    8192 __devm_ioremap+0x94/0xa4 phys=0x02a30000 ioremap
> 0xe2fcb2be-0x83ac2ff4   20480 __devm_ioremap+0x94/0xa4 phys=0x02020000 ioremap
> 0x83ac2ff4-0x498e66da    8192 __devm_ioremap+0x94/0xa4 phys=0x02a38000 ioremap
> 0xda200768-0x9519b5b7   20480 __devm_ioremap+0x94/0xa4 phys=0x021e8000 ioremap
> 0x9519b5b7-0xd8066315    8192 __devm_ioremap+0x94/0xa4 phys=0x02a20000 ioremap
> 0x327c6cd3-0xb09836e5   20480 __devm_ioremap+0x94/0xa4 phys=0x021f4000 ioremap
> 0xb09836e5-0x2ee61e13    8192 __devm_ioremap+0x94/0xa4 phys=0x02a68000 ioremap
> 0x28a28e71-0xfb74b75d   40960 __devm_ioremap+0x94/0xa4 phys=0x00120000 ioremap
> 0xfb74b75d-0x94731aa5    8192 __devm_ioremap+0x94/0xa4 phys=0x02a40000 ioremap
> 0x94731aa5-0x9ed95f4b   20480 __devm_ioremap+0x94/0xa4 phys=0x00130000 ioremap
> 0x9ed95f4b-0xb6679e93    8192 __devm_ioremap+0x94/0xa4 phys=0x02a48000 ioremap
> 0xd2083a49-0xd15b1ee5   20480 __devm_ioremap+0x94/0xa4 phys=0x00134000 ioremap
> 0xd15b1ee5-0xb873e80d    8192 __devm_ioremap+0x94/0xa4 phys=0x02a58000 ioremap
> 0xb873e80d-0xad853c5f    8192 __devm_ioremap+0x94/0xa4 phys=0x02b80000 ioremap
> 0xad853c5f-0x727a169b    8192 __devm_ioremap+0x94/0xa4 phys=0x02a60000 ioremap
> 0x79bcf223-0xd8778c7f  528384 devm_pci_remap_cfgspace+0x3c/0x74
> phys=0x01f00000 ioremap
> 0xd8778c7f-0xcd8f995b  135168 dma_common_contiguous_remap+0x88/0xa4 dma-coherent
> 0xcd8f995b-0x0e93c50d    8192 dma_common_contiguous_remap+0x88/0xa4 dma-coherent
> 0x0e93c50d-0x35d018fd   20480 __devm_ioremap+0x94/0xa4 phys=0x02204000 ioremap
> 0x35d018fd-0x30dd9119  528384 dma_common_contiguous_remap+0x88/0xa4 dma-coherent
> 0x30dd9119-0x1d49a1b3    8192 __devm_ioremap+0x94/0xa4 phys=0x02b40000 ioremap
> 0x1d49a1b3-0xe202a461    8192 __devm_ioremap+0x94/0xa4 phys=0x02a50000 ioremap
> 0x3c5f9898-0x7c998da8  135168 __devm_ioremap+0x94/0xa4 phys=0x02700000 ioremap
> 0x0be6bff2-0xe617431b   12288 __devm_ioremap+0x94/0xa4 phys=0x00112000 ioremap
> 0xe617431b-0x1894871f    8192 __pci_enable_msix_range+0x1b4/0x50c
> phys=0x01420000 ioremap
> 0xcc3e24ea-0x24fc33d0   69632 __devm_ioremap+0x94/0xa4 phys=0x02760000 ioremap
> 0x24fc33d0-0x2ad2fe2c   81920 pcpu_create_chunk+0x14c/0x290 pages=19 vmalloc
> 0x064e8962-0x041a1631    8192 __devm_ioremap+0x94/0xa4 phys=0x02184000 ioremap
> 0x041a1631-0xa78f78b0  135168 __devm_ioremap+0x94/0xa4 phys=0x02b00000 ioremap
> 0x482eea6f-0xa04223bd   12288 __devm_ioremap+0x94/0xa4 phys=0x00114000 ioremap
> 0xa04223bd-0x47cd64d8    8192 __devm_ioremap+0x94/0xa4 phys=0x02184000 ioremap
> 0x496ff4b8-0x1b8cd27f   69632 __devm_ioremap+0x94/0xa4 phys=0x02b60000 ioremap
> 0x1b8cd27f-0x9a03a792 1576960 dma_common_contiguous_remap+0x88/0xa4 dma-coherent
> 0x9e844161-0x46bbc5c3    8192 dma_common_contiguous_remap+0x88/0xa4 dma-coherent
> 0x46bbc5c3-0x061f37bb   20480 __devm_ioremap+0x94/0xa4 phys=0x02200000 ioremap
> 0x061f37bb-0x099e44f8   98304 dma_common_contiguous_remap+0x88/0xa4 dma-coherent
> 0x099e44f8-0x5a73428f   36864 iscsi_target_init_module+0xb4/0x234
> pages=8 vmalloc
> 0x5a73428f-0x6b24094e   20480 dma_common_contiguous_remap+0x88/0xa4 dma-coherent
> 0x8763af88-0xc279660f   20480 __devm_ioremap+0x94/0xa4 phys=0x0200c000 ioremap
> 0xc279660f-0x0746510e    8192 dma_common_contiguous_remap+0x88/0xa4 dma-coherent
> 0xc42e58a5-0x9bb92a15   20480 __devm_ioremap+0x94/0xa4 phys=0x02188000 ioremap
> 0x9bb92a15-0xbffbc968  135168 dma_common_contiguous_remap+0x88/0xa4 dma-coherent
> 0xbffbc968-0xc3135661   36864 dma_common_contiguous_remap+0x88/0xa4 dma-coherent
> 0x7f8906cc-0x57602490   20480 __devm_ioremap+0x94/0xa4 phys=0x021e4000 ioremap
> 0x57602490-0x32a0cd25    8192 dma_common_contiguous_remap+0x88/0xa4 dma-coherent
> 0x32a0cd25-0xccf592e4    8192 __devm_ioremap+0x94/0xa4 phys=0x02184000 ioremap
> 0xccf592e4-0xc3d5117e    8192 dma_common_contiguous_remap+0x88/0xa4 dma-coherent
> 0xd80eccd6-0x1eccdd8b  135168 igb_probe+0x150/0x10a4 phys=0x01400000 ioremap
> 0x1eccdd8b-0x360f1603    8192 dma_common_contiguous_remap+0x88/0xa4 dma-coherent
> 0x32fecfc9-0x71e47aa2   20480 __devm_ioremap+0x94/0xa4 phys=0x020c0000 ioremap
> 0x71e47aa2-0x5098c2fb    8192 dma_common_contiguous_remap+0x88/0xa4 dma-coherent
> 0xaf379216-0x24330e7c   20480 __devm_ioremap+0x94/0xa4 phys=0x02198000 ioremap
> 0x3dd54ba7-0x2392a17a   20480 __devm_ioremap+0x94/0xa4 phys=0x02034000 ioremap
> 0x2392a17a-0x1e11712d   16384 n_tty_open+0x10/0x9c pages=3 vmalloc
> 0x300b1fb4-0x33dba900   20480 __devm_ioremap+0x94/0xa4 phys=0x02028000 ioremap
> 0xf02c73a9-0xfa933595   20480 __devm_ioremap+0x94/0xa4 phys=0x0202c000 ioremap
> 0xbe5c4daa-0x6af5bd9c  528384 dma_common_contiguous_remap+0x88/0xa4 dma-coherent
> 0x6af5bd9c-0x9ea7250e  528384 dma_common_contiguous_remap+0x88/0xa4 dma-coherent
> 0x9ea7250e-0x74bbeefe 1294336 zstd_comp_init+0x58/0xb0 pages=315 vmalloc
> 0x74bbeefe-0x591c7299  163840 zstd_decomp_init+0x14/0x54 pages=39 vmalloc
> 0x591c7299-0x27154f89  274432 deflate_comp_init+0x20/0x90 pages=66 vmalloc
> 0x27154f89-0x3978b460   49152 deflate_decomp_init+0x14/0x58 pages=11 vmalloc
> 0x3978b460-0x99da8daa  212992 dma_common_contiguous_remap+0x88/0xa4 dma-coherent
> 0xe9a5ec5f-0xb0e53888  249856 __devm_ioremap+0x94/0xa4 phys=0x02040000 ioremap
> 0xb0e53888-0xc24dd16d  528384 dma_common_contiguous_remap+0x88/0xa4 dma-coherent
> 0xc02cb795-0x054951d9    4096 iotable_init+0x0/0xf0 phys=0x00a00000 ioremap
> 0x32815c21-0x48bd192d 2097152 pci_reserve_io+0x0/0x30 ioremap
> 0xba73986b-0x4f91845f  311296 pcpu_get_vm_areas+0x0/0x10c0 vmalloc
> 0x4f91845f-0x86cbfbfa  311296 pcpu_get_vm_areas+0x0/0x10c0 vmalloc
> 0x17d9341e-0xbe008562   16384 unpurged vm_area
> 0xecfce701-0xd35ab9b8    8192 unpurged vm_area
> 0xce35bdb8-0xd0da9915    8192 unpurged vm_area
> 0x6b04db7d-0xb849bd1c 15609856 unpurged vm_area
> 0xe202a461-0x3c5f9898   73728 unpurged vm_area
> 0x7c998da8-0x0be6bff2   36864 unpurged vm_area
> 0x2ad2fe2c-0x064e8962   36864 unpurged vm_area
> 0xa78f78b0-0x482eea6f   36864 unpurged vm_area
> 0x9a03a792-0x9e844161  442368 unpurged vm_area
> 0x92d57223-0xd09758da  249856 unpurged vm_area
> 0xfa933595-0xbe5c4daa   36864 unpurged vm_area
> 
> Thanks for your help!
> 
> Tim
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: arm32 insecure W+X mapping
  2021-08-20 17:48         ` Robin Murphy
@ 2021-08-20 18:41           ` Tim Harvey
  2021-09-07 17:48             ` Tim Harvey
  0 siblings, 1 reply; 20+ messages in thread
From: Tim Harvey @ 2021-08-20 18:41 UTC (permalink / raw)
  To: Robin Murphy
  Cc: Russell King (Oracle),
	Linux ARM Mailing List, Shawn Guo, Fabio Estevam, Lee Jones,
	Pengutronix Kernel Team

On Fri, Aug 20, 2021 at 10:48 AM Robin Murphy <robin.murphy@arm.com> wrote:
>
> On 2021-08-20 17:06, Tim Harvey wrote:
> > On Thu, Aug 19, 2021 at 5:16 PM Russell King (Oracle)
> > <linux@armlinux.org.uk> wrote:
> >>
> >> On Thu, Aug 19, 2021 at 04:59:15PM -0700, Tim Harvey wrote:
> >>> On Thu, Aug 19, 2021 at 2:28 PM Russell King (Oracle)
> >>> <linux@armlinux.org.uk> wrote:
> >>>>
> >>>> On Thu, Aug 19, 2021 at 10:19:46AM -0700, Tim Harvey wrote:
> >>>>> Greetings,
> >>>>>
> >>>>> Since commit a8e53c151fe7 "(ARM: 8737/1: mm: dump: add checking for
> >>>>> writable and executable)" I've been seeing the following appear on my
> >>>>> arm32 kernel:
> >>>>>
> >>>>> arm/mm: Found insecure W+X mapping at address 0xf087d000
> >>>>> ...
> >>>>> Checked W+X mappings: FAILED, 1 W+X pages found
> >>>>>
> >>>>> As I haven't seen others report this I assume it's something unique to
> >>>>> my kernel configuration. How do I debug what is causing the insecure
> >>>>> page?
> >>>>
> >>>> If you check /proc/vmallocinfo, it should tell you the physical
> >>>> address that was mapped there, and the function that created the
> >>>> mapping. That should give enough clues to track it down.
> >>>>
> >>>
> >>> Russell,
> >>>
> >>> Thanks for the tip!
> >>>
> >>> # dmesg | grep insecure
> >>> [   13.219582] arm/mm: Found insecure W+X mapping at address 0xf087d000
> >>> # cat /proc/vmallocinfo | grep 0xf0
> >>> 0x5f3045dd-0xf0020e05   20480 imx6_pm_get_base+0x64/0x98 phys=0x020e0000 ioremap
> >>> 0xf0020e05-0x6e748217    8192 dma_common_contiguous_remap+0x88/0xa4 dma-coherent
> >>> 0x127639d7-0x334ee291    4096 iotable_init+0x0/0xf0 phys=0x00a00000 ioremap
> >>
> >> Oh... the kernel's %p pointer munging (for security reasons) is
> >> affecting your ability to debug your problem. Assuming this is a
> >> recent kernel, you can disable this by passing "no_hash_pointers"
> >> on the kernel command line. You should then see real addresses (and
> >> a big fat message at boot time about it.
> >>
> >
> > I'm using 5.13 and when I pass in 'no_hash_pointers' I do indeed see
> > the huge warning but I get similar results that I can't make sense of:
>
> Pointer hashing always trips me up too, so I thought I'd chuck my
> curiosity into the ring...
>
> Between the vmallocinfo and printk code, it looks like you need to set
> /proc/sys/kptr_restrict to 1 and be root (or have CAP_SYSLOG privilege)
> to get non-hashed addresses here. Because having only one way to confuse
> debugging would be far too easy, I guess :/
>

Robin,

Thanks, that's what I needed:

# uname -r
5.13.12
# cat /proc/cmdline
console=ttymxc1,115200 no_hash_pointers
# echo 1 > /proc/sys/kernel/kptr_restrict
# dmesg | grep insecure
[   13.247957] arm/mm: Found insecure W+X mapping at address 0xf087d000
# cat /proc/vmallocinfo | grep 0xf087d000
0xf0878000-0xf087d000   20480 of_iomap+0x44/0x68 phys=0x021b0000 ioremap
0xf087d000-0xf087f000    8192 imx6_pm_common_init+0x118/0x36c
phys=0x00900000 ioremap

Some debugging showed me that 0xf087d000 is 'suspend_ocram_base'
remapped from imx6q_suspend_init() (called form imx6_pm_common_init()
[1]
suspend_ocram_base = __arm_ioremap_exec(ocram_pbase,
MX6Q_SUSPEND_OCRAM_SIZE, false);

This should be throwing 'Checked W+X mappings: FAILED, 1 W+X pages
found' messages for all IMX6 users that have CONFIG_SUSPEND and
CONFIG_DEBUG_WX enabled so I'm adding the IMX6 players to the thread
to see if they know why this happens.

Best regards,

Tim
https://elixir.bootlin.com/linux/v5.13.12/source/arch/arm/mach-imx/pm-imx6.c#L509

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: arm32 insecure W+X mapping
  2021-08-20 18:41           ` Tim Harvey
@ 2021-09-07 17:48             ` Tim Harvey
  2021-09-07 19:22               ` Russell King (Oracle)
  2021-09-15  9:44               ` Fabio Estevam
  0 siblings, 2 replies; 20+ messages in thread
From: Tim Harvey @ 2021-09-07 17:48 UTC (permalink / raw)
  To: Shawn Guo, Fabio Estevam, Pengutronix Kernel Team
  Cc: Russell King (Oracle), Linux ARM Mailing List, Lee Jones, Robin Murphy

On Fri, Aug 20, 2021 at 11:41 AM Tim Harvey <tharvey@gateworks.com> wrote:
>
> On Fri, Aug 20, 2021 at 10:48 AM Robin Murphy <robin.murphy@arm.com> wrote:
> >
> > On 2021-08-20 17:06, Tim Harvey wrote:
> > > On Thu, Aug 19, 2021 at 5:16 PM Russell King (Oracle)
> > > <linux@armlinux.org.uk> wrote:
> > >>
> > >> On Thu, Aug 19, 2021 at 04:59:15PM -0700, Tim Harvey wrote:
> > >>> On Thu, Aug 19, 2021 at 2:28 PM Russell King (Oracle)
> > >>> <linux@armlinux.org.uk> wrote:
> > >>>>
> > >>>> On Thu, Aug 19, 2021 at 10:19:46AM -0700, Tim Harvey wrote:
> > >>>>> Greetings,
> > >>>>>
> > >>>>> Since commit a8e53c151fe7 "(ARM: 8737/1: mm: dump: add checking for
> > >>>>> writable and executable)" I've been seeing the following appear on my
> > >>>>> arm32 kernel:
> > >>>>>
> > >>>>> arm/mm: Found insecure W+X mapping at address 0xf087d000
> > >>>>> ...
> > >>>>> Checked W+X mappings: FAILED, 1 W+X pages found
> > >>>>>
> > >>>>> As I haven't seen others report this I assume it's something unique to
> > >>>>> my kernel configuration. How do I debug what is causing the insecure
> > >>>>> page?
> > >>>>
> > >>>> If you check /proc/vmallocinfo, it should tell you the physical
> > >>>> address that was mapped there, and the function that created the
> > >>>> mapping. That should give enough clues to track it down.
> > >>>>
> > >>>
> > >>> Russell,
> > >>>
> > >>> Thanks for the tip!
> > >>>
> > >>> # dmesg | grep insecure
> > >>> [   13.219582] arm/mm: Found insecure W+X mapping at address 0xf087d000
> > >>> # cat /proc/vmallocinfo | grep 0xf0
> > >>> 0x5f3045dd-0xf0020e05   20480 imx6_pm_get_base+0x64/0x98 phys=0x020e0000 ioremap
> > >>> 0xf0020e05-0x6e748217    8192 dma_common_contiguous_remap+0x88/0xa4 dma-coherent
> > >>> 0x127639d7-0x334ee291    4096 iotable_init+0x0/0xf0 phys=0x00a00000 ioremap
> > >>
> > >> Oh... the kernel's %p pointer munging (for security reasons) is
> > >> affecting your ability to debug your problem. Assuming this is a
> > >> recent kernel, you can disable this by passing "no_hash_pointers"
> > >> on the kernel command line. You should then see real addresses (and
> > >> a big fat message at boot time about it.
> > >>
> > >
> > > I'm using 5.13 and when I pass in 'no_hash_pointers' I do indeed see
> > > the huge warning but I get similar results that I can't make sense of:
> >
> > Pointer hashing always trips me up too, so I thought I'd chuck my
> > curiosity into the ring...
> >
> > Between the vmallocinfo and printk code, it looks like you need to set
> > /proc/sys/kptr_restrict to 1 and be root (or have CAP_SYSLOG privilege)
> > to get non-hashed addresses here. Because having only one way to confuse
> > debugging would be far too easy, I guess :/
> >
>
> Robin,
>
> Thanks, that's what I needed:
>
> # uname -r
> 5.13.12
> # cat /proc/cmdline
> console=ttymxc1,115200 no_hash_pointers
> # echo 1 > /proc/sys/kernel/kptr_restrict
> # dmesg | grep insecure
> [   13.247957] arm/mm: Found insecure W+X mapping at address 0xf087d000
> # cat /proc/vmallocinfo | grep 0xf087d000
> 0xf0878000-0xf087d000   20480 of_iomap+0x44/0x68 phys=0x021b0000 ioremap
> 0xf087d000-0xf087f000    8192 imx6_pm_common_init+0x118/0x36c
> phys=0x00900000 ioremap
>
> Some debugging showed me that 0xf087d000 is 'suspend_ocram_base'
> remapped from imx6q_suspend_init() (called form imx6_pm_common_init()
> [1]
> suspend_ocram_base = __arm_ioremap_exec(ocram_pbase,
> MX6Q_SUSPEND_OCRAM_SIZE, false);
>
> This should be throwing 'Checked W+X mappings: FAILED, 1 W+X pages
> found' messages for all IMX6 users that have CONFIG_SUSPEND and
> CONFIG_DEBUG_WX enabled so I'm adding the IMX6 players to the thread
> to see if they know why this happens.
>

Shawn, Fabio and Pengutronix Kernel team,

Do you know why we get 'Checked W+X mappings: FAILED, 1 W+X pages
found' messages for IMX6 with CONFIG_SUSPEND and CONFIG_DEBUG_WX
enabled due to to __arm_ioremap_exec call remapping ocram? [1]

Best regards,

Tim
[1] https://elixir.bootlin.com/linux/v5.13.12/source/arch/arm/mach-imx/pm-imx6.c#L509

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: arm32 insecure W+X mapping
  2021-09-07 17:48             ` Tim Harvey
@ 2021-09-07 19:22               ` Russell King (Oracle)
  2021-09-15  9:44               ` Fabio Estevam
  1 sibling, 0 replies; 20+ messages in thread
From: Russell King (Oracle) @ 2021-09-07 19:22 UTC (permalink / raw)
  To: Tim Harvey
  Cc: Shawn Guo, Fabio Estevam, Pengutronix Kernel Team,
	Linux ARM Mailing List, Lee Jones, Robin Murphy

On Tue, Sep 07, 2021 at 10:48:49AM -0700, Tim Harvey wrote:
> On Fri, Aug 20, 2021 at 11:41 AM Tim Harvey <tharvey@gateworks.com> wrote:
> > # uname -r
> > 5.13.12
> > # cat /proc/cmdline
> > console=ttymxc1,115200 no_hash_pointers
> > # echo 1 > /proc/sys/kernel/kptr_restrict
> > # dmesg | grep insecure
> > [   13.247957] arm/mm: Found insecure W+X mapping at address 0xf087d000
> > # cat /proc/vmallocinfo | grep 0xf087d000
> > 0xf0878000-0xf087d000   20480 of_iomap+0x44/0x68 phys=0x021b0000 ioremap
> > 0xf087d000-0xf087f000    8192 imx6_pm_common_init+0x118/0x36c
> > phys=0x00900000 ioremap
> >
> > Some debugging showed me that 0xf087d000 is 'suspend_ocram_base'
> > remapped from imx6q_suspend_init() (called form imx6_pm_common_init()
> > [1]
> > suspend_ocram_base = __arm_ioremap_exec(ocram_pbase,
> > MX6Q_SUSPEND_OCRAM_SIZE, false);
> >
> > This should be throwing 'Checked W+X mappings: FAILED, 1 W+X pages
> > found' messages for all IMX6 users that have CONFIG_SUSPEND and
> > CONFIG_DEBUG_WX enabled so I'm adding the IMX6 players to the thread
> > to see if they know why this happens.
> >
> 
> Shawn, Fabio and Pengutronix Kernel team,
> 
> Do you know why we get 'Checked W+X mappings: FAILED, 1 W+X pages
> found' messages for IMX6 with CONFIG_SUSPEND and CONFIG_DEBUG_WX
> enabled due to to __arm_ioremap_exec call remapping ocram? [1]

The current situation looks like the OCRAM is used to store some
suspend/resume code (see arch/arm/mach-imx/suspend-imx6.S), along
with some data.

It looks like once the code has been copied and the data has been
written, the mapping is left as-is - it isn't changed to be
read-only-execute. However, I don't think we have any APIs to do
that on iomem.

set_memory_ro() could be leveraged to do it _if_ we are certain
the memory is not mapped using a section mapping, but that would
depend on the size and alignment of the mapping.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: arm32 insecure W+X mapping
  2021-09-07 17:48             ` Tim Harvey
  2021-09-07 19:22               ` Russell King (Oracle)
@ 2021-09-15  9:44               ` Fabio Estevam
  2021-09-15 15:07                 ` Tim Harvey
  2021-09-20 16:22                 ` Russell King (Oracle)
  1 sibling, 2 replies; 20+ messages in thread
From: Fabio Estevam @ 2021-09-15  9:44 UTC (permalink / raw)
  To: Tim Harvey
  Cc: Shawn Guo, Pengutronix Kernel Team, Russell King (Oracle),
	Linux ARM Mailing List, Lee Jones, Robin Murphy, NXP Linux Team

Hi Tim,

[Adding the NXP folks]

On Tue, Sep 7, 2021 at 2:49 PM Tim Harvey <tharvey@gateworks.com> wrote:

> Shawn, Fabio and Pengutronix Kernel team,
>
> Do you know why we get 'Checked W+X mappings: FAILED, 1 W+X pages
> found' messages for IMX6 with CONFIG_SUSPEND and CONFIG_DEBUG_WX
> enabled due to to __arm_ioremap_exec call remapping ocram? [1]

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!

Also, suspend/resume is not working as expected:

# echo enabled > /sys/class/tty/ttymxc0/power/wakeup
# echo mem >  /sys/power/state

(Sometimes it reboots the board, sometimes it does not enter in suspend).

I haven't had a chance to debug this but just wanted to report it.

Regards,

Fabio Estevam

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: arm32 insecure W+X mapping
  2021-09-15  9:44               ` Fabio Estevam
@ 2021-09-15 15:07                 ` Tim Harvey
  2021-09-20 16:22                 ` Russell King (Oracle)
  1 sibling, 0 replies; 20+ messages in thread
From: Tim Harvey @ 2021-09-15 15:07 UTC (permalink / raw)
  To: Fabio Estevam
  Cc: Shawn Guo, Pengutronix Kernel Team, Russell King (Oracle),
	Linux ARM Mailing List, Lee Jones, Robin Murphy, NXP Linux Team

On Wed, Sep 15, 2021 at 2:45 AM Fabio Estevam <festevam@gmail.com> wrote:
>
> Hi Tim,
>
> [Adding the NXP folks]
>
> On Tue, Sep 7, 2021 at 2:49 PM Tim Harvey <tharvey@gateworks.com> wrote:
>
> > Shawn, Fabio and Pengutronix Kernel team,
> >
> > Do you know why we get 'Checked W+X mappings: FAILED, 1 W+X pages
> > found' messages for IMX6 with CONFIG_SUSPEND and CONFIG_DEBUG_WX
> > enabled due to to __arm_ioremap_exec call remapping ocram? [1]
>
> 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!
>
> Also, suspend/resume is not working as expected:
>
> # echo enabled > /sys/class/tty/ttymxc0/power/wakeup
> # echo mem >  /sys/power/state
>
> (Sometimes it reboots the board, sometimes it does not enter in suspend).
>
> I haven't had a chance to debug this but just wanted to report it.
>

Fabio,

I don't see how this would be related. The warning and kernel dump are
a security warning that a page is left writable which could be used as
an attack vector. It doesn't constitute a bug necessarily but it is a
possible security hole that should be fixed. As Russell mentions there
would need to be some functions created to deal with it properly.

Best regards,

Tim

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: arm32 insecure W+X mapping
  2021-09-15  9:44               ` Fabio Estevam
  2021-09-15 15:07                 ` Tim Harvey
@ 2021-09-20 16:22                 ` Russell King (Oracle)
  2021-09-20 20:56                   ` Tim Harvey
  1 sibling, 1 reply; 20+ messages in thread
From: Russell King (Oracle) @ 2021-09-20 16:22 UTC (permalink / raw)
  To: Fabio Estevam
  Cc: Tim Harvey, Shawn Guo, Pengutronix Kernel Team,
	Linux ARM Mailing List, Lee Jones, Robin Murphy, NXP Linux Team

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@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?

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: arm32 insecure W+X mapping
  2021-09-20 16:22                 ` Russell King (Oracle)
@ 2021-09-20 20:56                   ` Tim Harvey
  2021-09-20 21:13                     ` Russell King (Oracle)
  0 siblings, 1 reply; 20+ messages in thread
From: Tim Harvey @ 2021-09-20 20:56 UTC (permalink / raw)
  To: Russell King (Oracle)
  Cc: Fabio Estevam, Shawn Guo, Pengutronix Kernel Team,
	Linux ARM Mailing List, Lee Jones, Robin Murphy, NXP Linux Team

On Mon, Sep 20, 2021 at 9:22 AM Russell King (Oracle)
<linux@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@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.

Tim

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: arm32 insecure W+X mapping
  2021-09-20 20:56                   ` Tim Harvey
@ 2021-09-20 21:13                     ` Russell King (Oracle)
  2021-09-20 22:53                       ` Tim Harvey
  0 siblings, 1 reply; 20+ messages in thread
From: Russell King (Oracle) @ 2021-09-20 21:13 UTC (permalink / raw)
  To: Tim Harvey
  Cc: Fabio Estevam, Shawn Guo, Pengutronix Kernel Team,
	Linux ARM Mailing List, Lee Jones, Robin Murphy, NXP Linux Team

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

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: arm32 insecure W+X mapping
  2021-09-20 21:13                     ` Russell King (Oracle)
@ 2021-09-20 22:53                       ` Tim Harvey
  2021-09-20 23:12                         ` Fabio Estevam
  2021-09-20 23:19                         ` Russell King (Oracle)
  0 siblings, 2 replies; 20+ messages in thread
From: Tim Harvey @ 2021-09-20 22:53 UTC (permalink / raw)
  To: Russell King (Oracle), Fabio Estevam
  Cc: Shawn Guo, Pengutronix Kernel Team, Linux ARM Mailing List,
	Lee Jones, Robin Murphy, NXP Linux Team

On Mon, Sep 20, 2021 at 2:13 PM Russell King (Oracle)
<linux@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@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@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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: arm32 insecure W+X mapping
  2021-09-20 22:53                       ` Tim Harvey
@ 2021-09-20 23:12                         ` Fabio Estevam
  2021-09-20 23:19                         ` Russell King (Oracle)
  1 sibling, 0 replies; 20+ messages in thread
From: Fabio Estevam @ 2021-09-20 23:12 UTC (permalink / raw)
  To: Tim Harvey
  Cc: Russell King (Oracle),
	Shawn Guo, Pengutronix Kernel Team, Linux ARM Mailing List,
	Lee Jones, Robin Murphy, NXP Linux Team

Hi Tim,

On Mon, Sep 20, 2021 at 7:53 PM Tim Harvey <tharvey@gateworks.com> wrote:

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

Thanks for bisecting it. Yes, after reverting such commit,
suspend/resume works again.

The first time it takes a long time to resume:

# echo enabled > /sys/class/tty/ttymxc0/power/wakeup
# echo mem >  /sys/power/state
[   15.599190] PM: suspend entry (deep)
[   15.640341] Filesystems sync: 0.036 seconds
[   64.492708] imx-sdma 20ec000.sdma: external firmware not found,
using ROM firmware

From 15 to 69s it is just waiting to suspend.

[   69.611037] Freezing user space processes ...
[   69.614849] cfg80211: failed to load regulatory.db
[   69.625538] (elapsed 0.014 seconds) done.
[   69.630737] OOM killer disabled.
[   69.634227] Freezing remaining freezable tasks ... (elapsed 0.006
seconds) done.
[   69.648817] printk: Suspending console(s) (use no_console_suspend to debug)
[   70.269165] PM: suspend devices took 0.610 seconds
[   70.288058] Disabling non-boot CPUs ...
[   70.362203] mmc1: queuing unknown CIS tuple 0x01 [d9 01 ff] (3 bytes)
[   70.371768] mmc1: queuing unknown CIS tuple 0x1a [01 01 00 02 07] (5 bytes)
[   70.375904] mmc1: queuing unknown CIS tuple 0x1b [c1 41 30 30 ff ff
32 00] (8 bytes)
[   70.376832] mmc1: queuing unknown CIS tuple 0x14 [] (0 bytes)
[   70.400971] PM: resume devices took 0.100 seconds
[   70.445566] OOM killer enabled.
[   70.448883] Restarting tasks ... done.
[   70.461806] PM: suspend exit

Subsequent times, there is no such delay.

# echo mem >  /sys/power/state
[   87.687476] PM: suspend entry (deep)
[   87.755373] Filesystems sync: 0.064 seconds
[   87.764171] Freezing user space processes ... (elapsed 0.002 seconds) done.
[   87.773544] OOM killer disabled.
[   87.776968] Freezing remaining freezable tasks ... (elapsed 0.002
seconds) done.
[   87.786944] printk: Suspending console(s) (use no_console_suspend to debug)
[   88.405849] PM: suspend devices took 0.610 seconds
[   88.423879] Disabling non-boot CPUs ...
[   88.492122] mmc1: queuing unknown CIS tuple 0x01 [d9 01 ff] (3 bytes)
[   88.501684] mmc1: queuing unknown CIS tuple 0x1a [01 01 00 02 07] (5 bytes)
[   88.505837] mmc1: queuing unknown CIS tuple 0x1b [c1 41 30 30 ff ff
32 00] (8 bytes)
[   88.506782] mmc1: queuing unknown CIS tuple 0x14 [] (0 bytes)
[   88.529321] PM: resume devices took 0.090 seconds
[   88.573766] OOM killer enabled.
[   88.577090] Restarting tasks ... done.
[   88.587390] PM: suspend exit
#

That's an orthogonal issue though.

I will send the revert.

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

Yes, agreed.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: arm32 insecure W+X mapping
  2021-09-20 22:53                       ` Tim Harvey
  2021-09-20 23:12                         ` Fabio Estevam
@ 2021-09-20 23:19                         ` Russell King (Oracle)
  2021-09-21  0:21                           ` Fabio Estevam
  2021-09-22  3:37                           ` Shawn Guo
  1 sibling, 2 replies; 20+ messages in thread
From: Russell King (Oracle) @ 2021-09-20 23:19 UTC (permalink / raw)
  To: Tim Harvey, Shawn Guo
  Cc: Fabio Estevam, Pengutronix Kernel Team, Linux ARM Mailing List,
	Lee Jones, Robin Murphy, NXP Linux Team

On Mon, Sep 20, 2021 at 03:53:24PM -0700, Tim Harvey wrote:
> On Mon, Sep 20, 2021 at 2:13 PM Russell King (Oracle)
> <linux@armlinux.org.uk> wrote:
> > 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.

I agree - the assumption in the commit message for that commit is
incomplete:

        imx6q_enet_phy_init();
-
-       of_platform_default_populate(NULL, NULL, NULL);
-
        imx_anatop_init();
        cpu_is_imx6q() ?  imx6q_pm_init() : imx6dl_pm_init();

Both imx6q_pm_init() and imx6dl_pm_init(), which then eventually call
into imx6q_suspend_init(), which wants the OCRAM device to exist. That
only happens by that point due to the of_platform_default_populate()
call just above.

Shawn - please can we get cc8870bf4c3a ("ARM: imx6q: drop of_platform_default_populate() from init_machine")
reverted? Thanks.

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

Yes, also agreed.

I think what I'd like to see is a wrapper around set_memory_ro() that
gets passed the __iomem pointer and size. change_memory_common()
should accept it as the ioremap() will be located in the vmalloc
area which change_memory_common() accepts.

Probably something like:

void __arm_iomem_set_ro(void __iomem *ptr, size_t size)
{
	set_memory_ro((unsigned long)ptr, PAGE_ALIGN(size) / PAGE_SIZE);
}

in arch/arm/mm/ioremap.c would be nice, just after __arm_ioremap_exec().
I've probably just written the patch in wordy words. :) Something like
this (untested):

diff --git a/arch/arm/include/asm/io.h b/arch/arm/include/asm/io.h
index f74944c6fe8d..c576fa7d9bf8 100644
--- a/arch/arm/include/asm/io.h
+++ b/arch/arm/include/asm/io.h
@@ -138,6 +138,7 @@ extern void __iomem *__arm_ioremap_caller(phys_addr_t, size_t, unsigned int,
 	void *);
 extern void __iomem *__arm_ioremap_pfn(unsigned long, unsigned long, size_t, unsigned int);
 extern void __iomem *__arm_ioremap_exec(phys_addr_t, size_t, bool cached);
+void __arm_iomem_set_ro(void __iomem *ptr, size_t size);
 extern void __iounmap(volatile void __iomem *addr);
 
 extern void __iomem * (*arch_ioremap_caller)(phys_addr_t, size_t,
diff --git a/arch/arm/mach-imx/pm-imx6.c b/arch/arm/mach-imx/pm-imx6.c
index 9244437cb1b9..5c16257872a5 100644
--- a/arch/arm/mach-imx/pm-imx6.c
+++ b/arch/arm/mach-imx/pm-imx6.c
@@ -571,6 +571,8 @@ static int __init imx6q_suspend_init(const struct imx6_pm_socdata *socdata)
 		&imx6_suspend,
 		MX6Q_SUSPEND_OCRAM_SIZE - sizeof(*pm_info));
 
+	__arm_iomem_set_ro(suspend_ocram_base, MX6Q_SUSPEND_OCRAM_SIZE);
+
 	goto put_device;
 
 pl310_cache_map_failed:
diff --git a/arch/arm/mm/ioremap.c b/arch/arm/mm/ioremap.c
index 80fb5a4a5c05..6e830b9418c9 100644
--- a/arch/arm/mm/ioremap.c
+++ b/arch/arm/mm/ioremap.c
@@ -36,6 +36,7 @@
 #include <asm/mmu_context.h>
 #include <asm/pgalloc.h>
 #include <asm/tlbflush.h>
+#include <asm/set_memory.h>
 #include <asm/system_info.h>
 
 #include <asm/mach/map.h>
@@ -401,6 +402,11 @@ __arm_ioremap_exec(phys_addr_t phys_addr, size_t size, bool cached)
 			__builtin_return_address(0));
 }
 
+void __arm_iomem_set_ro(void __iomem *ptr, size_t size)
+{
+	set_memory_ro((unsigned long)ptr, PAGE_ALIGN(size) / PAGE_SIZE);
+}
+
 void *arch_memremap_wb(phys_addr_t phys_addr, size_t size)
 {
 	return (__force void *)arch_ioremap_caller(phys_addr, size,

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related	[flat|nested] 20+ messages in thread

* Re: arm32 insecure W+X mapping
  2021-09-20 23:19                         ` Russell King (Oracle)
@ 2021-09-21  0:21                           ` Fabio Estevam
  2021-09-21 15:13                             ` Russell King (Oracle)
  2021-09-22  3:37                           ` Shawn Guo
  1 sibling, 1 reply; 20+ messages in thread
From: Fabio Estevam @ 2021-09-21  0:21 UTC (permalink / raw)
  To: Russell King (Oracle)
  Cc: Tim Harvey, Shawn Guo, Pengutronix Kernel Team,
	Linux ARM Mailing List, Lee Jones, Robin Murphy, NXP Linux Team

Hi Russell,

On Mon, Sep 20, 2021 at 8:19 PM Russell King (Oracle)
<linux@armlinux.org.uk> wrote:

> I think what I'd like to see is a wrapper around set_memory_ro() that
> gets passed the __iomem pointer and size. change_memory_common()
> should accept it as the ioremap() will be located in the vmalloc
> area which change_memory_common() accepts.
>
> Probably something like:
>
> void __arm_iomem_set_ro(void __iomem *ptr, size_t size)
> {
>         set_memory_ro((unsigned long)ptr, PAGE_ALIGN(size) / PAGE_SIZE);
> }
>
> in arch/arm/mm/ioremap.c would be nice, just after __arm_ioremap_exec().
> I've probably just written the patch in wordy words. :) Something like
> this (untested):

Just tested your patch and DEBUG_WX is happy now:

[    5.610346] Checked W+X mappings: passed, no W+X pages found

Thanks a lot, appreciate it!

Tested-by: Fabio Estevam <festevam@gmail.com>

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: arm32 insecure W+X mapping
  2021-09-21  0:21                           ` Fabio Estevam
@ 2021-09-21 15:13                             ` Russell King (Oracle)
  0 siblings, 0 replies; 20+ messages in thread
From: Russell King (Oracle) @ 2021-09-21 15:13 UTC (permalink / raw)
  To: Fabio Estevam, Shawn Guo
  Cc: Tim Harvey, Pengutronix Kernel Team, Linux ARM Mailing List,
	Lee Jones, Robin Murphy, NXP Linux Team

On Mon, Sep 20, 2021 at 09:21:53PM -0300, Fabio Estevam wrote:
> Hi Russell,
> 
> On Mon, Sep 20, 2021 at 8:19 PM Russell King (Oracle)
> <linux@armlinux.org.uk> wrote:
> 
> > I think what I'd like to see is a wrapper around set_memory_ro() that
> > gets passed the __iomem pointer and size. change_memory_common()
> > should accept it as the ioremap() will be located in the vmalloc
> > area which change_memory_common() accepts.
> >
> > Probably something like:
> >
> > void __arm_iomem_set_ro(void __iomem *ptr, size_t size)
> > {
> >         set_memory_ro((unsigned long)ptr, PAGE_ALIGN(size) / PAGE_SIZE);
> > }
> >
> > in arch/arm/mm/ioremap.c would be nice, just after __arm_ioremap_exec().
> > I've probably just written the patch in wordy words. :) Something like
> > this (untested):
> 
> Just tested your patch and DEBUG_WX is happy now:
> 
> [    5.610346] Checked W+X mappings: passed, no W+X pages found
> 
> Thanks a lot, appreciate it!
> 
> Tested-by: Fabio Estevam <festevam@gmail.com>

Thanks, I've split the patch into two parts - one for generic ARM bits
and the other touching imx6 bits. They'll probably be in linux-next
this evening. I would like an Ack from Shawn on the imx6 part of the
patch before I sent it to Linus at the next merge window.

At some point, I will be rebuilding my "misc" branch - I've just thrown
a bunch of commits on top of the 5.14-rc based branch from the last
cycle as a temporary measure.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: arm32 insecure W+X mapping
  2021-09-20 23:19                         ` Russell King (Oracle)
  2021-09-21  0:21                           ` Fabio Estevam
@ 2021-09-22  3:37                           ` Shawn Guo
  1 sibling, 0 replies; 20+ messages in thread
From: Shawn Guo @ 2021-09-22  3:37 UTC (permalink / raw)
  To: Russell King (Oracle)
  Cc: Tim Harvey, Fabio Estevam, Pengutronix Kernel Team,
	Linux ARM Mailing List, Lee Jones, Robin Murphy, NXP Linux Team

On Tue, Sep 21, 2021 at 12:19:36AM +0100, Russell King (Oracle) wrote:
> diff --git a/arch/arm/mach-imx/pm-imx6.c b/arch/arm/mach-imx/pm-imx6.c
> index 9244437cb1b9..5c16257872a5 100644
> --- a/arch/arm/mach-imx/pm-imx6.c
> +++ b/arch/arm/mach-imx/pm-imx6.c
> @@ -571,6 +571,8 @@ static int __init imx6q_suspend_init(const struct imx6_pm_socdata *socdata)
>  		&imx6_suspend,
>  		MX6Q_SUSPEND_OCRAM_SIZE - sizeof(*pm_info));
>  
> +	__arm_iomem_set_ro(suspend_ocram_base, MX6Q_SUSPEND_OCRAM_SIZE);
> +
>  	goto put_device;
>  
>  pl310_cache_map_failed:

Acked-by: Shawn Guo <shawnguo@kernel.org>

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 20+ messages in thread

end of thread, other threads:[~2021-09-22  3:39 UTC | newest]

Thread overview: 20+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-08-19 17:19 arm32 insecure W+X mapping Tim Harvey
2021-08-19 21:28 ` Russell King (Oracle)
2021-08-19 23:59   ` Tim Harvey
2021-08-20  0:16     ` Russell King (Oracle)
2021-08-20 16:06       ` Tim Harvey
2021-08-20 17:48         ` Robin Murphy
2021-08-20 18:41           ` Tim Harvey
2021-09-07 17:48             ` Tim Harvey
2021-09-07 19:22               ` Russell King (Oracle)
2021-09-15  9:44               ` Fabio Estevam
2021-09-15 15:07                 ` Tim Harvey
2021-09-20 16:22                 ` Russell King (Oracle)
2021-09-20 20:56                   ` Tim Harvey
2021-09-20 21:13                     ` Russell King (Oracle)
2021-09-20 22:53                       ` Tim Harvey
2021-09-20 23:12                         ` Fabio Estevam
2021-09-20 23:19                         ` Russell King (Oracle)
2021-09-21  0:21                           ` Fabio Estevam
2021-09-21 15:13                             ` Russell King (Oracle)
2021-09-22  3:37                           ` Shawn Guo

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.