内核热补丁能替代重启吗?

安全公告发布之后，运维面对的矛盾很具体：内核漏洞需要尽快消除暴露面，业务方却排不出维护窗口。内核热补丁（livepatch）因此常被当成折中答案。不重启，在运行中的内核上替换掉有问题的函数。它能争取时间，但很难替代版本收敛。

补丁的边界由机制决定

热补丁的工作方式是函数级替换：把目标函数的执行重定向到修正后的实现。这要求被修补的代码路径可以被安全地中断和替换。当修复涉及数据结构布局调整、内存分配语义变化，或落在启动早期等难以截获的路径上时，厂商通常无法提供对应补丁。因此能否热修补，取决于漏洞本身是否被纳入可打补丁的范围，而不是机器上装了热补丁组件就自动免疫所有内核问题。

通知消失不等于风险消失

打了热补丁之后，uname -r 通常仍指向旧内核，磁盘上的内核包可能已经是新版本。更微妙的是，重启标记文件可能因为热补丁的存在而被移除，登录横幅不再提示。把“没有提示”读成“不需要重启”，是这类环境里最容易发生的误判。原文的判断口径值得沿用：标记文件不存在并不必然等于不需要重启，最终仍要对照 uname -r 与已安装内核版本。

它管不到用户态

热补丁作用于内核态，对 glibc、OpenSSL 这类共享库的更新无能为力。库文件在磁盘上换新后，长期驻留的进程仍然映射着已被删除的旧文件，lsof +L1 可以把这些进程筛出来；服务主进程启动时间早于更新时间的，也要单独确认。这部分只能靠重启或重载对应服务完成，热补丁不提供任何捷径。

收敛仍是必要动作

热补丁持续累积，运行内核的实际代码与磁盘内核包之间的偏离会越来越大，排查故障时的可解释性随之下降。更稳妥的处置是：用热补丁覆盖到下一个维护窗口，在窗口内重启进入正式内核，让补丁状态收敛。它的定位是压缩暴露窗口，并未取消维护窗口。

判断一次热补丁是否够用，可以落到几个问题上：本次漏洞涉及的代码路径是否被补丁覆盖；uname -r 与已安装内核之间是否仍有差距；关键用户态库是否有进程仍在映射旧文件；下一次重启窗口是否已经排定。这四点都答得清楚，热补丁才算用对了位置。