劫持sys呼叫

Question

我正在编写一个内核模块，我需要劫持/包装一些sys调用。我粗暴地强迫sys_call_table地址，我使用cr0来禁用/启用页面保护。到目前为止还不错(一旦代码完成，我就会公开整个代码，这样如果有人愿意，我就可以更新这个问题)。

无论如何，我已经注意到，如果我劫持__NR_sys_read，当我卸载内核模块时，我会得到一个内核oops，并且所有konsoles (KDE)崩溃。请注意，__NR_sys_open或__NR_sys_write不会发生这种情况。

我想知道为什么会这样。有什么想法吗？

PS:请不要走KProbes的道路，我已经知道了，我不可能使用它，因为最终的产品应该是可用的，而不需要重新编译整个内核。

编辑：(添加信息)

我在卸载前恢复原来的功能。此外，我还创建了两个测试用例，一个只使用_write，另一个使用_read。有_write的那个可以很好地卸载，但是有_read的那个会卸载然后崩溃内核)。

编辑：(源代码)

我现在在家，所以我现在不能发布源代码，但是如果有人想要的话，我一到工作就可以发布一个示例代码。(~5小时)

Answer 1

这可能是因为内核线程当前在read中--如果调用读钩子没有锁定模块，则无法安全卸载。

这就解释了"konsoles“(?)由于他们目前可能正在执行read syscall，因此正在崩溃，等待数据。当他们从实际的syscall返回时，他们将跳入您的函数所在的位置，从而导致问题。

卸载将是混乱的，但您需要首先删除钩子，然后等待所有调用退出钩子功能，然后卸载模块。

我最近一直在玩linux挂钩，但我绝不是一个内核大师，所以我认为如果这是离题的话。

PS: This technique可能比蛮横的sys_call_table更可靠。如果sys_close已经上钩的话，我所见过的强力技术往往会导致内核恐慌。