From: Salvatore Bonaccorso <carnil@debian.org>
To: "Mike Rapoport (Microsoft)" <rppt@kernel.org>
Cc: Andy Lutomirski <luto@kernel.org>, Borislav Petkov <bp@alien8.de>,
Dave Hansen <dave.hansen@linux.intel.com>,
Ingo Molnar <mingo@redhat.com>,
Peter Zijlstra <peterz@infradead.org>,
Thomas Gleixner <tglx@kernel.org>,
x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
Rick Edgecombe <rick.p.edgecombe@intel.com>,
Tom Lendacky <thomas.lendacky@amd.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 5/9] x86/mm/pat: don't warn about W^X violations before mark_rodata_ro()
Date: Thu, 12 Nov 2026 22:46:03 +0100 [thread overview]
Message-ID: <avYzmyX5eR814o5L@eldamar.lan> (raw)
In-Reply-To: <20261112-fixes-x86-v1-5-791adb8d6670@kernel.org>
Hi Mike,
On Thu, Nov 12, 2026 at 06:31:10PM +0200, Mike Rapoport (Microsoft) wrote:
> The kernel text is mapped RWX until mark_rodata_ro(), so W^X violations
> that verify_rwx() detects before that can be false positives.
>
> CHECK_WX is enabled by default with STRICT_KERNEL_RWX and it reports
> mappings that remain W+X after mark_rodata_ro().
>
> Drop the warning about W^X violations before mark_rodata_ro().
>
> Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
> ---
> arch/x86/mm/pat/set_memory.c | 18 ++++++------------
> 1 file changed, 6 insertions(+), 12 deletions(-)
>
> diff --git a/arch/x86/mm/pat/set_memory.c b/arch/x86/mm/pat/set_memory.c
> index a1bea16a3c3bb..a674433850dc9 100644
> --- a/arch/x86/mm/pat/set_memory.c
> +++ b/arch/x86/mm/pat/set_memory.c
> @@ -718,21 +718,15 @@ static inline pgprot_t verify_rwx(pgprot_t old, pgprot_t new, unsigned long star
> if (!rw || nx)
> return new;
>
> - end = start + npg * PAGE_SIZE - 1;
> -
> /*
> - * If the kernel text is still RWX, gently complain, this could be a
> - * false positive.
> - * Once debug_checkwx() becomes mandatory for CONFIG_STRICT_KERNEL_RWX,
> - * the warning can be removed completely.
> + * The kernel text is RWX until mark_rodata_ro() and the entire kernel
> + * page table is verified after the text is protected, so there is no
> + * need to warn.
> */
> - if (!kernel_set_to_readonly) {
> - pr_warn_once("CPA detected W^X violation: %016llx -> %016llx range: 0x%016lx - 0x%016lx PFN %lx\n",
> - (unsigned long long)pgprot_val(old),
> - (unsigned long long)pgprot_val(new),
> - start, end, pfn);
> + if (!kernel_set_to_readonly)
> return new;
> - }
> +
> + end = start + npg * PAGE_SIZE - 1;
>
> WARN_ONCE(1, "CPA detected W^X violation: %016llx -> %016llx range: 0x%016lx - 0x%016lx PFN %lx\n",
> (unsigned long long)pgprot_val(old),
>
> --
> 2.53.0
Does this need to carry a
Fixes: ea6fd393cb9e ("x86/mm/pat: Use pr_warn() for early W^X warnings")
?
On a system booted into 6.12.117 (from 6.12.116) I see:
[ 1.091378] ------------[ cut here ]------------
[ 1.092538] CPA detected W^X violation: 0000000000000121 -> 0000000000000123 range: 0xffffffffc0477000 - 0xffffffffc0477fff PFN 109c1f
[ 1.093994] WARNING: CPU: 5 PID: 222 at arch/x86/mm/pat/set_memory.c:665 __change_page_attr_set_clr+0xf62/0xfb0
[ 1.095730] Modules linked in:
[ 1.097101] CPU: 5 UID: 0 PID: 222 Comm: (udev-worker) Not tainted 6.12.117+deb13-amd64 #1 Debian 6.12.117-1
[ 1.098671] Hardware name: LENOVO 20XXS1FU00/20XXS1FU00, BIOS N32ETA2W (1.78 ) 07/23/2026
[ 1.100096] RIP: 0010:__change_page_attr_set_clr+0xf62/0xfb0
[ 1.101357] Code: 09 ea e9 19 fa ff ff 48 8b 4c 24 10 49 89 d9 4c 89 d6 48 89 54 24 08 48 c7 c7 38 43 95 a6 c6 05 d1 fd d7 01 01 e8 9e 76 01 00 <0f> 0b 48 8b 54 24 08 e9 22 fc ff ff 80 3d ba fd d7 01 00 0f 85 15
[ 1.102928] RSP: 0018:ffffd02d40557648 EFLAGS: 00010286
[ 1.104241] RAX: 0000000000000000 RBX: 0000000000109c1f RCX: 0000000000000003
[ 1.105561] RDX: 0000000000000000 RSI: 0000000000000003 RDI: 0000000000000001
[ 1.107204] RBP: 0000000109c1f121 R08: 0000000000000000 R09: ffffd02d405574c8
[ 1.108503] R10: ffffffffa70b43a8 R11: 0000000000000003 R12: 0000000000000001
[ 1.109816] R13: 0000000109c1f121 R14: 0000000000000001 R15: ffffffffc0477000
[ 1.111556] FS: 00007fcf08a6b980(0000) GS:ffff88c4bf680000(0000) knlGS:0000000000000000
[ 1.112888] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 1.114279] CR2: 000055cf7979a138 CR3: 000000014061e006 CR4: 0000000000f70ef0
[ 1.115600] PKRU: 55555554
[ 1.116935] Call Trace:
[ 1.118345] <TASK>
[ 1.119677] ? __purge_vmap_area_lazy+0x13c/0x320
[ 1.120979] ? _vm_unmap_aliases+0x217/0x260
[ 1.122392] change_page_attr_set_clr+0x104/0x1a0
[ 1.123702] set_memory_rw+0x28/0x40
[ 1.125019] apply_retpolines+0x19c/0x4c0
[ 1.126404] module_finalize+0x209/0x3e0
[ 1.127690] ? add_kallsyms+0x293/0x310
[ 1.128985] load_module+0x17f1/0x1e90
[ 1.130318] ? init_module_from_file+0x89/0xe0
[ 1.131586] init_module_from_file+0x89/0xe0
[ 1.132873] idempotent_init_module+0x11e/0x310
[ 1.134175] __x64_sys_finit_module+0x5e/0xb0
[ 1.135433] do_syscall_64+0x87/0x1b0
[ 1.136706] ? vfs_read+0x24d/0x370
[ 1.137967] ? __x64_sys_pread64+0x98/0xd0
[ 1.139652] ? arch_exit_to_user_mode_prepare.isra.0+0x16/0xa0
[ 1.140905] ? syscall_exit_to_user_mode+0x37/0x1b0
[ 1.142172] ? do_syscall_64+0x93/0x1b0
[ 1.143402] ? __count_memcg_events+0x53/0xf0
[ 1.144644] ? count_memcg_events.constprop.0+0x1a/0x30
[ 1.145859] ? handle_mm_fault+0x1bb/0x2c0
[ 1.147452] ? do_user_addr_fault+0x367/0x650
[ 1.148626] ? clear_bhb_loop+0x70/0xc0
[ 1.149809] ? clear_bhb_loop+0x70/0xc0
[ 1.151303] entry_SYSCALL_64_after_hwframe+0x76/0x7e
[ 1.152445] RIP: 0033:0x7fcf095cf4f9
[ 1.153586] Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d e7 68 0d 00 f7 d8 64 89 01 48
[ 1.155067] RSP: 002b:00007fffd10634a8 EFLAGS: 00000246 ORIG_RAX: 0000000000000139
[ 1.156238] RAX: ffffffffffffffda RBX: 000055cf79783110 RCX: 00007fcf095cf4f9
[ 1.157419] RDX: 0000000000000004 RSI: 00007fcf07cf944d RDI: 0000000000000010
[ 1.158766] RBP: 0000000000000004 R08: 0000000000000000 R09: 000055cf79763ba0
[ 1.159927] R10: 0000000000000000 R11: 0000000000000246 R12: 00007fcf07cf944d
[ 1.161090] R13: 0000000000020000 R14: 000055cf79784bc0 R15: 0000000000000000
[ 1.162318] </TASK>
[ 1.163460] ---[ end trace 0000000000000000 ]---
ea6fd393cb9e ("x86/mm/pat: Use pr_warn() for early W^X warnings") from
7.4-rc1 was backported to 7.3.4, 6.18.63 and 6.12.117.
And Nathan reported it here, which is marked in the Closes field:
https://lore.kernel.org/all/20260905044253.GA3816371@ax162 . The fixes
tags would allow to make it pick us as well for the respective stable
series were needed?
Regards,
Salvatore
next prev parent reply other threads:[~2026-11-12 21:46 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-12 16:31 [PATCH 0/9] x86/mm: CPA robustness fixes and cleanups Mike Rapoport (Microsoft)
2026-11-12 16:31 ` [PATCH 1/9] x86/mm/pat: flush the TLB when only an alias mapping changed Mike Rapoport (Microsoft)
2026-11-12 16:31 ` [PATCH 2/9] x86/mm: don't set kernel_set_to_readonly when write protecting fails Mike Rapoport (Microsoft)
2026-11-12 16:31 ` [PATCH 3/9] x86/mm/pat: don't populate page tables in set_memory_{en,de}crypted() Mike Rapoport (Microsoft)
2026-11-12 16:31 ` [PATCH 4/9] x86/mm/pat: don't BUG() on inconsistent page count Mike Rapoport (Microsoft)
2026-11-12 16:31 ` [PATCH 5/9] x86/mm/pat: don't warn about W^X violations before mark_rodata_ro() Mike Rapoport (Microsoft)
2026-11-12 21:46 ` Salvatore Bonaccorso [this message]
2026-11-15 6:25 ` Mike Rapoport
2026-11-12 16:31 ` [PATCH 6/9] x86/mm/pat: remove CPA_ARRAY Mike Rapoport (Microsoft)
2026-11-12 16:31 ` [PATCH 7/9] x86/mm/pat: pass the address to CPA by value Mike Rapoport (Microsoft)
2026-11-12 16:31 ` [PATCH 8/9] x86/mm/pat: move the collapse of large pages out of cpa_flush() Mike Rapoport (Microsoft)
2026-11-12 16:31 ` [PATCH 9/9] x86/mm/pat: use cpa_flush() on CPA errors Mike Rapoport (Microsoft)
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=avYzmyX5eR814o5L@eldamar.lan \
--to=carnil@debian.org \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=rick.p.edgecombe@intel.com \
--cc=rppt@kernel.org \
--cc=tglx@kernel.org \
--cc=thomas.lendacky@amd.com \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.