由于师兄基于VT的modules无法正常工作,因此本来基于它的监视目标进程的写操作,并且重新定向的工作只好用一般的修改系统调用的形式完成.其中找到sys_call_table地址的代码是网络上某某前辈的,在此表达我的感谢!不过确实如某人所说,很多网络上的转的文章都是基本复制-粘贴,基本没有自己动手的过程.其实这个问题,我是这样看的,本身我也转了一篇关于Oops调试模块的文章,但是不知道是如何原因,里面的一些命令在我的redhat-linux上面一条也没有运行起来,不是遇到permission deny,就是遇到file-symbol-not-find,等等诸如此类问题.因此我认为每个写技术性博客文章的大牛们(提问除外)都应该有义务让自己的文章的可移植性强一些,其实通俗一点的说就是把每条指令或者命令的目的,以及需要的工具,涉及的库都说明了,这样也就免除了后来人因为这样那样的问题满世界的百度/谷歌什么的.
回归正题,前面说到要截获目标进程的写操作,并进行重新定向,使用修改系统调用的思路大概10年前就有人实现了,自己再做这个主要是把其中的逻辑搞好了,并测试通过,等师兄的VT modules正常工作就移植过去.
在这个过程中,最让人头痛的是由于系统中很多操作需要调用到sys_write,因此不能在里面使用printk,因为printk也是会产生sys_write调用.于是要找到其中的导致系统crash的bugs就必须通过调试modules来实现.但是,我是一个新手,于是就在各个大牛之间的技术博客中来回寻找思路,未遂.
生活还得继续,毕设也一样,因此我会继续这方面的学习,并将解决问题的过程以一种移植性比较高的形式写出来.
前几天发现我内核crash主要来自于 get_task_struct()这个内联汇编函数没有写好,有寄存器副作用的问题,相比较使用current这个当前task_struct指针就可以避免相应问题。
阅读(954) | 评论(0) | 转发(0) |