x86/Kconfig: enable ROX cache in execmem when STRICT_KERNEL_RWX is set

[PATCH] x86/Kconfig: enable ROX cache in execmem when STRICT_KERNEL_RWX is set

Posted by Mike Rapoport 2 months, 3 weeks ago

From: "Mike Rapoport (Microsoft)" <rppt@kernel.org>

Dan Moulding reported that kernel configured without modules produces
"Found insecure W+X mapping at address 0xffffffffc0247000" warining:

[    6.022847] ------------[ cut here ]------------
[    6.023020] x86/mm: Found insecure W+X mapping at address 0xffffffffc0247000
[    6.023200] WARNING: CPU: 5 PID: 1 at arch/x86/mm/dump_pagetables.c:246 note_page+0x6ec/0x790
[    6.023381] CPU: 5 UID: 0 PID: 1 Comm: swapper/0 Tainted: G                T   6.16.0-rc6 #1 PREEMPT
[    6.023558] Tainted: [T]=RANDSTRUCT
...
[    6.031153] x86/mm: Checked W+X mappings: FAILED, 10 W+X pages found.

The 10 W+X pages are the pages allocated for ITS thunks. With
CONFIG_MODULES disabled, CONFIG_STRICT_MODULE_RWX does not exist and ROX
cache in execmem is not enabled so execmem_restore_rox() becomes an empty
stub.

Enabling ROX cache when CONFIG_STRICT_KERNEL_RWX is set solves the issue and
makes ITS thunks memory properly protected.

It also ensures that memory containing ITS thunks is mapped with 2M pages
for kernels compiled without modules.

Reported-by: Dan Moulding <dan@danm.net>
Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
---
 arch/x86/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 8bed9030ad47..d6d8050683ae 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -89,7 +89,7 @@ config X86
 	select ARCH_HAS_DMA_OPS			if GART_IOMMU || XEN
 	select ARCH_HAS_EARLY_DEBUG		if KGDB
 	select ARCH_HAS_ELF_RANDOMIZE
-	select ARCH_HAS_EXECMEM_ROX		if X86_64 && STRICT_MODULE_RWX
+	select ARCH_HAS_EXECMEM_ROX		if X86_64 && (STRICT_KERNEL_RWX || STRICT_MODULE_RWX)
 	select ARCH_HAS_FAST_MULTIPLIER
 	select ARCH_HAS_FORTIFY_SOURCE
 	select ARCH_HAS_GCOV_PROFILE_ALL

base-commit: 347e9f5043c89695b01e66b3ed111755afcf1911
-- 
2.47.2

[PATCH] x86/Kconfig: enable ROX cache in execmem when STRICT_KERNEL_RWX is set

Posted by Dan Moulding 6 days, 6 hours ago

> Dan Moulding reported that kernel configured without modules produces
> "Found insecure W+X mapping at address 0xffffffffc0247000" warining:
>
> [    6.022847] ------------[ cut here ]------------
> [    6.023020] x86/mm: Found insecure W+X mapping at address 0xffffffffc0247000
> [    6.023200] WARNING: CPU: 5 PID: 1 at arch/x86/mm/dump_pagetables.c:246 note_page+0x6ec/0x790
> [    6.023381] CPU: 5 UID: 0 PID: 1 Comm: swapper/0 Tainted: G                T   6.16.0-rc6 #1 PREEMPT
> [    6.023558] Tainted: [T]=RANDSTRUCT
> ...
> [    6.031153] x86/mm: Checked W+X mappings: FAILED, 10 W+X pages found.
>
> The 10 W+X pages are the pages allocated for ITS thunks. With
> CONFIG_MODULES disabled, CONFIG_STRICT_MODULE_RWX does not exist and ROX
> cache in execmem is not enabled so execmem_restore_rox() becomes an empty
> stub.
>
> Enabling ROX cache when CONFIG_STRICT_KERNEL_RWX is set solves the issue and
> makes ITS thunks memory properly protected.
>
> It also ensures that memory containing ITS thunks is mapped with 2M pages
> for kernels compiled without modules.
>
> Reported-by: Dan Moulding <dan@danm.net>
> Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
> ---
>  arch/x86/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index 8bed9030ad47..d6d8050683ae 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -89,7 +89,7 @@ config X86
>  	select ARCH_HAS_DMA_OPS			if GART_IOMMU || XEN
>  	select ARCH_HAS_EARLY_DEBUG		if KGDB
>  	select ARCH_HAS_ELF_RANDOMIZE
> -	select ARCH_HAS_EXECMEM_ROX		if X86_64 && STRICT_MODULE_RWX
> +	select ARCH_HAS_EXECMEM_ROX		if X86_64 && (STRICT_KERNEL_RWX || STRICT_MODULE_RWX)
>  	select ARCH_HAS_FAST_MULTIPLIER
>  	select ARCH_HAS_FORTIFY_SOURCE
>  	select ARCH_HAS_GCOV_PROFILE_ALL
>
> base-commit: 347e9f5043c89695b01e66b3ed111755afcf1911
> --
> 2.47.2

Just a friendly ping to see if this patch has been applied. I haven't
been able to find it in any of the relevant trees, and wanted to be
sure it doesn't slip through the cracks.

Thanks!

-- Dan