劫持系统调用

我正在写一个内核模块,我需要劫持/包装一些系统调用。 我很强制sys_call_table地址,我正在使用cr0来禁用/启用页面保护。 到目前为止,这么好(我会公布整个代码,所以我可以更新这个问题,如果有人想要的话)。

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

我想知道为什么会发生这种情况。 有任何想法吗?

PS:请不要去KProbe的方式,我已经知道了它,我不能使用它,因为最终产品应该是可用的,无需重新编译整个内核。

编辑 :(添加信息)

卸载前我恢复原来的function。 另外,我创build了两个testing用例,一个用_write而另一个用_read 。 用_write那个卸载好了,但是带有_read那个卸载然后崩溃了内核)。

编辑 :(源代码)

我现在在家,所以我现在不能发布源代码,但如果有人想要,我可以发布一个示例代码,只要我开始工作。 (约5小时)

Solutions Collecting From Web of "劫持系统调用"

这可能是因为内核线程当前在read内部 – 如果调用您的读取钩子不会锁定模块,则不能安全卸载。

这将解释“konsoles”(?)崩溃,因为它们可能正在执行read系统调用,正在等待数据。 当他们从实际的系统调用返回时,他们会跳到你的函数曾经是的地方,造成这个问题。

卸载将是混乱的,但你需要先删除挂钩,然后等待所有的调用者退出挂钩功能,然后卸载模块。

我最近一直在玩linux系统调用钩子,但我不是内核大师,所以我认为这是不是基地。

PS: 这个技术可能比强制sys_call_table更加可靠。 我已经看到的蛮力技术倾向于内核恐慌,如果sys_close已经挂钩。