[ 242.761062] dss_read, 1177, pos: 36864, count:4096
[ 242.761062] dss_read, 1181, payload_length: 44434
[ 242.761063] dss_read, 1235, begin: 36864, end:40960, try_read:4096
[ 242.761063] dss_read, 1236, jump file header,then begin: 37376, try_read:4096
[ 242.761064] dss_read, 1243, real_read:4096
[ 242.761066] dss_read, 1272, real_copy:4096
[ 242.761216] dss_read, 1177, pos: 32768, count:4096
[ 242.761217] dss_read, 1181, payload_length: 44434
[ 242.761217] dss_read, 1235, begin: 32768, end:36864, try_read:4096
[ 242.761217] dss_read, 1236, jump file header,then begin: 33280, try_read:4096
[ 242.761219] dss_read, 1243, real_read:4096
[ 242.761223] dss_read, 1272, real_copy:4096
[ 242.826149] dss_openat, 1111, plain file [/opt/apps/cn.wps.wps-office-pro/files/kingsoft/wps-office/office6/mui/zh_CN/kliteui.rcc] was opened, fd:29, Pid:[5627]
[ 242.826165] dss_close, 2501, close sensitive fd [29] and remove linknode
我内核里hook了openat、 read、wirte、close等系统调用。
蓝色输出是在读加密文件，读着读着不读了，要close了，可是还没等到close结束，应用程序的另一个线程（姑且这么认为）就开始打开另外一个文件kliteui.rcc了，返回的fd值居然和前边被读的文件的fd值是一样的。同一个进程里不应该有这样的事情啊
close的代码如下：
代码： 全选
long dss_close(struct pt_regs* regs)
{
int fd = regs->di;
spin_lock(&dss_fd_lock);
struct list_head* link;
list_for_each(link, &dss_fd_list)
{
DSS_FD_INFO* item = (DSS_FD_INFO*)link;
if (item->fd == fd && item->pid == current->pid)
{
printk("%s, %d, close sensitive fd [%d] and remove linknode\n", __FUNCTION__, __LINE__, fd);
list_del(&item->list);
kfree(item);
break;
}
}
spin_unlock(&dss_fd_lock);
//这个操作要放在这个函数的最后边，否则可能发生时序不对的问题。
//如果放在循环体前边，可能会发生fd还没有从链表里释放时就由于当前进程的其它线程调用openat函数而返回相同的fd，别处判断fd是否涉密时就会出错
long ret = orig_close(regs);
return ret;
}
