linux - 内核模块的安全卸载

Question

我必须编写 LKM，它会拦截一些系统调用。解决方案是:

1. 找到sys_call_table符号的地址，检查地址是否正确(例如检查sys_call_table[__NR_close]指向sys_close的地址)
2. 禁用中断
3. 禁用 CR0 中的 WP 位
4. 将 sys_call_table[__NR_close] 更改为我自己的函数
5. 启用 WP 位
6. 启用中断。模块加载工作正常。

但是，如何安全卸载模块呢？

考虑当我将 sys_call_table 恢复到它的原始状态并且模块被卸载时的情况——如果内核仍在其他 CPU 上的其他进程的系统调用上下文中执行来 self 的模块的代码怎么办？我将在内核模式下出现页面错误(因为带有模块代码段的页面不再可用，因为模块已卸载)。共享资源是 sys_call_table 中的条目。如果我可以访问这个受锁保护的条目 - 那么我就可以安全地卸载我的模块。

但是，由于内核系统调用处理程序没有任何这种锁(例如 arch/x86/kernel/entry_32.S)——这意味着没有安全的方法来卸载我的模块？是真的吗？

更新1

我需要获取有关旧内核(其中 fanotify(2) 不可用)的文件访问的信息，从 2.4 内核版本开始。我需要此信息以通过防病毒引擎执行访问扫描。

Answer 1

你是对的，一旦你完成了这个，就没有安全的方法来卸载你的模块。这就是为什么不赞成以这种方式替换/包装系统调用表条目的原因之一。

在最近的版本中，sys_call_table 不是一个导出符号——至少部分是为了阻止这件事。

理论上有可能支持更健壮的系统调用替换机制，但内核维护者认为整个概念充满了错误和困惑的可能性，因此他们拒绝支持它。 (网络搜索将显示 linux 内核邮件列表上关于此主题的几个很久以前的辩论。)

(作为几年前使用完全相同技术的人在这里发言。)

您当然可以这样做。然后，您可以“冒着风险”卸载您的模块——因此可能会导致内核 panic (但当然它可能会在 99% 的时间内工作)。或者您根本不允许卸载您的模块(需要重新启动才能升级或卸载)。