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