no_hash_pointers 内核参数详解：从哈希指针到真实地址调试

如果你调过内核模块，一定见过这种输出：[ 1234.567890] foo: invalid pointer 00000000deadbeef，或者更早时代的老内核上那串神秘的(ptrval)。一串哈希值，你说它是地址吧，和芯片手册、寄存器基址完全对不上；你说它不是地址吧，它又确实是从指针算出来的。内核在默认情况下会对%p做哈希化处理，本意是防止内核地址泄露给普通用户，但到了驱动调试、崩溃转储分析这类场景，它就变成了纯粹添乱的存在。no_hash_pointers就是用来关掉这层伪装的启动参数：它告诉内核，这次启动你老老实实把真实指针地址打出来，别打码了。

这篇文章写给两类人：一类是被哈希指针折磨的内核驱动开发者，另一类是做崩溃转储、ftrace 分析和内核机制研究的同学。看完你会明白这个参数到底改了什么、怎么传参、验证效果如何，以及为什么我坚持只在特定调试环境下开它。

1. 内核为什么要给指针“打码”？

1.1 从%p到哈希：printk 的指针策略演变

很久以前，内核的printk("%p", ptr)会直接打印指针的原始数值，比如ffffffff81000000。这对调试者非常友好，但对攻击者也很友好：一旦能读到内核日志，内核代码段、堆、栈的地址布局就全暴露了，KASLR 的随机化效果会被大幅削弱。

于是内核社区开始收紧指针打印策略。最先出现的是%pK，这个格式符受kptr_restrict控制，只有特权进程能拿到真实地址。但现实很骨感：内核代码里有海量的%p调用，大部分开发者并不会刻意区分%p和%pK。如果放任%p直接打印真实地址，信息泄露的口子依然存在。

后来内核换了个思路：把默认的%p输出从“真实地址”改成“基于随机密钥计算的哈希值”。哈希值看起来像地址，但实际和真实地址没有可反推的映射关系。这样的好处是：既能保留%p作为调试信息载体的作用，又不至于直接把内存布局兜底给普通用户。代价就是我们今天吐槽的“日志里一串乱码”。

顺带一提，如果你在较老的内核上见过(ptrval)，那是另一段历史：当时格式化函数会被调用两次，第一次为了计算输出长度，第二次真正生成字符串，结果第一次打印了真实地址，第二次被占位符(ptrval)替换，反而造成信息泄露。所以后来才被哈希方案取代。

1.2%pK、%px、no_hash_pointers的三角关系

搞清楚它们三者的区别，是使用no_hash_pointers的前提。

no_hash_pointers影响的是%p这条主链路。它并不会把所有格式符都变成“真实地址输出”。有些读者会误以为开了这个参数，%pK也能无条件看到地址，这是不对的：%pK的权限闸门依然存在，no_hash_pointers只是解开了哈希这一层，并没有解开权限这一层。

1.3 哈希是怎么算出来的：随机密钥与 siphash

具体实现在lib/vsprintf.c的ptr_to_id()里。内核维护了一个启动时随机生成的密钥，叫ptr_key，通过get_random_bytes()填充。每次开机这个密钥都不同，所以同一个指针在两次启动之间哈希值会不一样，这是很多人感到困惑的一点：上次日志里是0x12345678，这次变成了0x87654321，别慌，这是哈希密钥换了，不是内核抽风。

哈希算法用的是 siphash，一种对短输入非常友好且抗碰撞的伪随机函数。siphash 的输入是真实指针值和随机密钥，输出变成一串看起来像地址的数字，再被格式化成十六进制。整个过程很快，热路径上的开销可以忽略不计。

从使用者角度看，这个机制很像快递柜：你看到的是取件码，不是柜子编号。no_hash_pointers做的事情，是让快递员直接把柜号写给你。

2. no_hash_pointers 到底改变了什么？

2.1 源码层面：一个全局变量的“闸门”

在lib/vsprintf.c里，有一个全局变量no_hash_pointers，默认是 false。启动参数解析阶段，内核遇到命令行里的no_hash_pointers时，会把它置为 true。它被声明为__ro_after_init，也就是说一旦初始化完成，就变成只读，运行时不能通过/sys或/proc动态修改。

ptr_to_id()的逻辑大致是这样的：

static char *ptr_to_id(char *buf, char *end, const void *ptr, struct printf_spec spec) { if (no_hash_pointers) { return pointer_string(buf, end, ptr, spec); } /* 否则用 ptr_key 对 ptr 做 siphash，输出哈希值 */ }

注意这只是逻辑骨架，真实代码还有各种边界处理，但核心思想就是这一层判断：参数在，走真实地址；参数不在，走哈希。这个设计非常简洁，也说明它本来就是一个面向调试和维护人员的功能，不打算做成可动态切换的开关。

2.2 影响范围：不止 dmesg，还有 trace 和 kallsyms

很多人以为no_hash_pointers只影响dmesg，其实它的影响面比想象中广。

第一块是内核日志，也就是printk家族。无论是pr_info、dev_err还是trace_printk，只要格式化串里用了%p，输出都会从哈希值变成真实地址。

第二块是 ftrace 输出。你用tracefs跟踪某个函数，参数里往往会有函数指针。哈希化之后，你看着00000000abcdef12没法快速判断它对应哪个函数，开了no_hash_pointers后就能直接和/proc/kallsyms里的符号地址对应上。

第三块是/proc/kallsyms。这个文件的情况稍微复杂一点，它同时受kptr_restrict和no_hash_pointers影响。整体规则维持“权限先行”的原则：如果权限检查不通过，no_hash_pointers不会越权放行；但权限检查通过后，它会让符号地址从全零或哈希状态变成真实地址。不同内核版本在细节上有微调，大方向不变。

2.3 与 kptr_restrict / nokaslr 的关系矩阵

这三个参数经常被放在一起讨论，但解决的问题完全不一样。

实际调试时，这三个参数经常搭配使用。比如你想让每次崩溃的地址都可复现，可以加nokaslr；但nokaslr不会让%p变成真实地址，还得靠no_hash_pointers。反过来，开了no_hash_pointers但没关 KASLR，地址每次启动还是不一样，这是正常的，不代表参数没生效。

我的建议是：调试早期启动阶段的问题时，两者一起加；调试运行时逻辑问题时，只加no_hash_pointers，保留 KASLR，尽量贴近真实部署环境。

3. 实操：如何正确开启并验证

3.1 三种常见传参方式与踩坑提醒

这个参数属于内核启动参数（boot parameter），必须在引导阶段传入。最常见的三种方式如下。

第一种，GRUB 2 管理的发行版。以我常用的环境为例，修改/etc/default/grub：

sudo vim /etc/default/grub

找到GRUB_CMDLINE_LINUX这一行，在里面追加参数：

GRUB_CMDLINE_LINUX="no_hash_pointers"

然后重新生成 GRUB 配置：

sudo update-grub

注意GRUB_CMDLINE_LINUX_DEFAULT和GRUB_CMDLINE_LINUX的区别：前者只影响默认引导项的正常启动，后者对包括恢复模式在内的所有引导项生效。我踩过的坑是，只把参数加到了_DEFAULT里，结果某次用旧内核引导时参数没生效，排查了半天才发现是没看/proc/cmdline。

第二种，嵌入式或开发板场景，通常是 U-Boot 环境变量：

setenv bootargs 'console=ttyS0,115200 no_hash_pointers' boot

第三种，临时调试最快的办法：在引导菜单界面直接编辑内核命令行。GRUB 菜单里按e，找到linux开头的行，在末尾追加no_hash_pointers，按Ctrl+X启动即可。这种方式重启后失效，适合快速验证行为。

参数加完之后，第一件事永远是确认它真的传进去了：

cat /proc/cmdline

如果这一行末尾能看到no_hash_pointers，说明参数已经被内核接收到。如果看不到，先别急着怀疑参数本身，回头检查 grub 配置或者 bootloader 有没有覆盖 cmdline 的逻辑。

3.2 用最小模块验证效果

光看/proc/cmdline还不够，最好实际观察%p的输出变化。写一个最小内核模块最快。

#include <linux/module.h> #include <linux/init.h> #include <linux/kernel.h> static int __init ptr_demo_init(void) { void *demo_ptr = (void *)0xffffffff81000000; pr_info("demo plain pointer: %p\n", demo_ptr); pr_info("demo restricted: %pK\n", demo_ptr); pr_info("demo raw pointer: %px\n", demo_ptr); return 0; } static void __exit ptr_demo_exit(void) { } module_init(ptr_demo_init); module_exit(ptr_demo_exit); MODULE_LICENSE("GPL");

编译加载后查 dmesg：

sudo dmesg | grep demo

没有no_hash_pointers时，第一行输出是一个稳定的十六进制哈希值，但和0xffffffff81000000没有直接对应关系；第二行大概率是全零，因为普通测试机的kptr_restrict默认不是 0；第三行不管加不加参数都是真实地址。

加了no_hash_pointers后，第一行会直接变成ffffffff81000000，这才是这个参数真正生效的铁证。

3.3 典型调试场景：从 dmesg 到崩溃转储

我平时最常用到它的场景有三个。

第一个是驱动开发中的地址对照。调试 DMA 描述符时，硬件日志会打出一个物理地址，而驱动代码里dev_err(&pdev->dev, "desc addr %p\n", desc);打印的是哈希值，两边根本对不上。开了no_hash_pointers，日志里的地址能直接和逻辑分析仪抓到的总线地址、芯片手册里的寄存器偏移互相印证，效率提升非常明显。

第二个是内核崩溃转储分析。系统 panic 之后，vmcore里的指针如果全是哈希值，用崩溃分析工具解析时就需要额外的符号映射，非常痛苦。如果提前在启动参数里加上no_hash_pointers，vmcore里的指针就是真实地址，配合System.map或vmlinux可以快速定位到具体函数。

第三个是 ftrace 和 eBPF 调试。跟踪一个内核函数时，参数里可能包含函数指针。哈希化之后，你对着 ftrace 输出无法判断它指向哪里；关闭哈希后，函数指针可以直接和kallsyms里的符号名对应起来，配合addr2line就能还原调用路径。

4. 常见误区与实战避坑

4.1 四个高频误区

第一个误区：以为这个参数可以运行时动态开关。它不行，__ro_after_init决定了它只能在启动阶段生效。想改变状态，只能重启。

第二个误区：以为它能让所有地址都“透明化”。实际上它只影响走哈希逻辑的%p输出，%pK的权限限制还在，/proc/kallsyms的权限检查也还在。它不是万能钥匙，更像是一把只开一扇门的钥匙。

第三个误区：把no_hash_pointers和kptr_restrict=0划等号。两者机制不同：前者关掉的是“哈希”这层加工，后者放开的是“权限”这扇门。测试时最直观的区别是，kptr_restrict=0时普通用户也能读某些受限指针，而no_hash_pointers不会改变权限模型。

第四个误区：忘记考虑 KASLR。有人在开发板上开了no_hash_pointers，每次重启发现同一个符号的地址不一样，就以为参数没生效。真实原因往往是 KASLR 在起作用，no_hash_pointers只是解除了哈希，并没有固定内核加载地址。想要地址固定，需要另外加nokaslr。

4.2 问题快查表

还有一个容易忽略的细节：如果你用串口调试早期启动日志，no_hash_pointers对earlycon同样生效，因为底层走的是同一套printf机制。这对接入早期 panic 信息非常有用。

4.3 安全底线：什么时候绝对不能开

这是我必须强调的部分。

no_hash_pointers本质上是主动关闭一项内核缓解措施。任何能读到内核日志的用户态进程，都可能从真实地址中推断出内核内存布局，进而辅助绕过 KASLR。以下场景我坚决不建议开：

• 生产环境，尤其是对外提供服务的机器；
• 多人共用的开发服务器，除非你能保证所有用户都是可信的；
• 处理敏感数据或受合规约束的环境。

如果确实需要调试，建议单独创建一个调试引导项，把no_hash_pointers只加在那个引导项里，日常默认引导保持原样。这样既保住了调试能力，又降低了长期暴露风险。

我在实际使用中还有个习惯：配合dmesg_restrict=1使用。这样即使开了no_hash_pointers，普通用户也读不到/dev/kmsg和dmesg，地址泄露面会小很多。当然，这不是绝对安全，根用户一样能看，但它把风险从“任意用户”缩小到了“特权用户”。

最后再分享一个小技巧：如果你只想临时看某个模块打印的真实指针，又不想为整个系统开启no_hash_pointers，可以在自己的调试代码里直接用%px而不是%p。它不受这个参数影响，始终输出真实地址。代价是你要自己为这行日志负责，别把它留在生产代码里。说到底，no_hash_pointers是调试阶段的工具，不是生产环境的常态配置。用完记得改回来。