Re: [PATCH] x86/its: Make ITS thunk pages read-only without the ROX execmem cache

[Mike Rapoport]

On Thu, Oct 01, 2026 at 08:24:50AM -0700, Dave Hansen wrote:
> On 10/1/26 06:22, Frédéric MARIE-JOSEPH wrote:
> > That's my first post so I hope I do things right. I found what seems to
> > me like a bug, and worked with Claude to find a patch. Hope it will be
> > usefull.
> 
> Your mailer is sending out HTML, but there was a plain-text version too,
> so the message at least made it to the archives. Using git-send-email is
> the most foolproof way to send these things, fwiw.
> 
> > With CONFIG_MODULES=n there is no STRICT_MODULE_RWX, so x86 does not
> > select ARCH_HAS_EXECMEM_ROX and execmem_restore_rox() is the stub that
> > returns 0.
> 
> Ugh. The origin of this seems to be:
> 
>          select ARCH_HAS_EXECMEM_ROX             if X86_64 &&
> STRICT_MODULE_RWX
> from:
> 
> > commit 47410d839fcda6890cb82828f874f97710982f24
> > Author: Mike Rapoport (Microsoft) <rppt@xxxxxxxxxx>
> > Date:   Tue Jun 3 14:14:42 2025 +0300
> > 
> >     x86/Kconfig: only enable ROX cache in execmem when STRICT_MODULE_RWX is set
> 
> That commit is trying to change execmem internal details via an
> arch-specific Kconfig tweak. It's also logically a bit silly that what
> an arch supports:
> 
> 	ARCH_HAS_EXECMEM_ROX
> 
> depends on a module-specific option:
> 
> 	STRICT_MODULE_RWX
> 
> If execmem is being too aggressive on for modules on !STRICT_MODULE_RWX
> configs, shouldn't the fix be in execmem *module* code?

I think we can only have !STRICT_MODULE_RWX when MODULES=n, so it's not
because we are lax with modules code, but because there are no modules.

And since STRICT_KERNEL_RWX is always enabled on x86, I think we we want
ROX caches everywhere except Xen PV.

A while ago Richard send a patch that added STRICT_KERNEL_RWX to that
Kconfig dependency 

https://lore.kernel.org/all/20260625090627.1501095-1-richard@xxxxxx/

but apparently it fell between the cracks.

Since STRICT_MODULE_RWX || STRICT_KERNEL_RWX is always true, I'd say that
we can just revert 47410d839fcda, especially as I have hard time
remembering why I did it in the first place :)
 
> Maybe something along the line of the lightly-tested attached patch? I
> see the "11 W+X pages found" message without it, and the message goes
> away when it is applied.

> 
> 
> ---
> 
>  b/arch/x86/Kconfig     |    2 +-
>  b/kernel/module/main.c |    3 ++-
>  2 files changed, 3 insertions(+), 2 deletions(-)
> 
> diff -puN arch/x86/Kconfig~x86-STRICT_MODULE_RWX arch/x86/Kconfig
> --- a/arch/x86/Kconfig~x86-STRICT_MODULE_RWX	2026-10-01 06:31:14.379577124 -0700
> +++ b/arch/x86/Kconfig	2026-10-01 06:31:39.777436090 -0700
> @@ -85,7 +85,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
>  	select ARCH_HAS_FAST_MULTIPLIER
>  	select ARCH_HAS_FORTIFY_SOURCE
>  	select ARCH_HAS_GCOV_PROFILE_ALL
> diff -puN kernel/module/main.c~x86-STRICT_MODULE_RWX kernel/module/main.c
> --- a/kernel/module/main.c~x86-STRICT_MODULE_RWX	2026-10-01 06:44:42.417795788 -0700
> +++ b/kernel/module/main.c	2026-10-01 06:51:28.048722976 -0700
> @@ -1355,7 +1355,8 @@ static int module_memory_alloc(struct mo
>  	if (!ptr)
>  		return -ENOMEM;
>  
> -	mod->mem[type].is_rox = execmem_is_rox(execmem_type);
> +	if (IS_ENABLED(STRICT_MODULE_RWX))
> +		mod->mem[type].is_rox = execmem_is_rox(execmem_type);
>  
>  	/*
>  	 * The pointer to these blocks of memory are stored on the module
> _


-- 
Sincerely yours,
Mike.