修改CR0.WP位无法安全覆写内核只读内存，因现代内核通过页表只读+CONFIG_STRICT_KERNEL_RWX等机制双重防护，即使清WP也会触发页错误；合法方式应使用set_memory_rw()等API。
不能在用户态或常规内核模块中安全、合法地通过修改 CR0 的 WP 位来覆写内核只读内存——这不是一个可工程化使用的“技巧”，而是已失效、高危且违反现代内核保护机制的操作。
为什么修改 CR0.WP 在现代系统上基本无效
自 Linux 内核 2.6.22（2007 年）起，默认启用 CONFIG_DEBUG_RODATA，此后演进为 CONFIG_STRICT_KERNEL_RWX（ARM64）和 CONFIG_DEBUG_WX（x86_64）。这些配置不仅设置页表级只读（PTE 的 U/S 和 R/W 位），还配合 CR0.WP=1 强制 CPU 拒绝写入只读页——但关键在于：内核自身会主动将关键数据段（如 .rodata、__start_rodata）映射为 **页表只读 + 用户不可访问**，此时即使你清掉 CR0.WP，CPU 仍因页表权限拒绝写入，触发 #PF（Page Fault）而非静默成功。
更现实的障碍：
-
CR0是特权寄存器，仅能在 ring 0 执行mov %rax, %cr0；用户态程序无权操作 - 现代内核（尤其是启用了 KPTI / SMAP / SMEP 的系统）会在上下文切换时重置或校验
CR0，手动修改后很快被覆盖 - 内核代码段（
.text）通常被标记为WP+XD/NX（执行禁用），关WP无法绕过NX位
真实场景中谁会动 CR0.WP？
仅限以下极少数可信环境：
立即学习“C++免费学习笔记（深入）”；
- 内核早期启动阶段（
head_64.S中），在建立完分页、启用CR4.PAE后，但尚未开启CONFIG_STRICT_KERNEL_RWX前的短暂窗口 - 某些 rootkit（如早期 FU ToR、KnL）在 patch 内核符号表前，会临时清
CR0.WP，但必须配合write_cr0()+clflush+ TLB 刷新，且极易被 EDR 检测到CR0异常变更 - 内核调试/开发环境（如 QEMU + GDB 单步），关闭
CONFIG_STRICT_KERNEL_RWX编译，并禁用 SMEP/SMAP，才可能观察到CR0.WP的原始行为
注意：write_cr0(read_cr0() & ~X86_CR0_WP) 这类代码若出现在加载的 LKM 中，大概率触发 kernel panic: "CR0.WP disabled in module" 或被 lockdep 报告为非法操作。
替代思路：内核中真正可行的只读内存修改方式
如果你的目标是动态 patch 内核行为（例如 hook 函数、修改 sysctl 值），应使用内核提供的安全接口，而非硬刚 CR0：
- 对变量：使用
__wr_after_init或__read_mostly属性声明，允许在初始化后有限修改 - 对函数：用
ftrace_set_filter()+register_ftrace_function()实现无侵入 hook - 对只读数据段：若必须修改（如 patch 符号地址），应调用
set_memory_rw()/set_memory_ro()修改页表权限，再用memcpy()，最后sync_icache_range()刷指令缓存 - 永远避免直接
*(long*)addr = new_val—— 即使CR0.WP=0，也需确保该地址所在页已通过set_memory_rw()解除页表只读
示例（合法）：
// addr 是 __rodata 中某变量地址（需先用 kallsyms_lookup_name() 获取）
if (set_memory_rw((unsigned long)addr & PAGE_MASK, 1))
return -EPERM;
*(volatile int*)addr = 42;
set_memory_ro((unsigned long)addr & PAGE_MASK, 1);
真正难的不是关 WP，而是让 CPU 和 MMU 同时“同意”你写——而现代内核的设计哲学就是不给你这个机会。任何绕过 set_memory_*() 系列 API 的裸寄存器操作，都意味着你已在内核稳定性和安全性边界之外。
