sys_execve鈎在3.5內核上

Question

我正在嘗試在x86_32的Linux內核v3.5中掛鈎sys_execve syscall。 我只需將sys_call_table條目地址更改為我的鈎子函數

asmlinkage long (*real_execve)( const char __user*, const char __user* const __user*,
                 const char __user* const __user* );
...
asmlinkage long hook_execve( const char __user* filename, const char __user* const __user* argv,
                    const char __user* const __user* envp )
{
    printk( "Called execve hook\n" );
    return real_execve( filename, argv, envp );
}
...
real_execve = (void*)sys_call_table[ __NR_execve ];
sys_call_table[ __NR_execve ] = (unsigned long)hook_execve;

我確實設置了用於修改sys_call_table條目的頁面權限，並且提到的方案對於另一個syscall（chdir，mkdir等）也很有效。 但是在execve掛鈎上，我得到了空指針取消引用：

Mar 11 14:18:08 mbz-debian kernel: [ 5590.596033] Called execve hook
Mar 11 14:18:08 mbz-debian kernel: [ 5590.596408] BUG: unable to handle kernel NULL pointer dereference at   (null)
Mar 11 14:18:08 mbz-debian kernel: [ 5590.596486] IP: [<  (null)>]   (null)
Mar 11 14:18:08 mbz-debian kernel: [ 5590.596526] *pdpt = 0000000032302001 *pde = 0000000000000000 
Mar 11 14:18:08 mbz-debian kernel: [ 5590.596584] Oops: 0010 [#1] SMP

由於arch/x86/kernel/entry_32.S ，我使用三個參數調用sys_execve，其中包含PTREGSCALL3(execve) 。 但是，我嘗試用四個參數調用它（添加struct pt_regs* ），但是我遇到了同樣的錯誤。 也許這種執行方法完全出問題了？ 還是我錯過了什么？

更新1

我發現sys_call_table[ __NR_execve ]實際上包含ptregs_execve地址（不是sys_execve ）。 在arch/x86/kernel/entry_32.S定義如下：

#define PTREGSCALL3(name) \
ENTRY(ptregs_##name) ; \
CFI_STARTPROC; \
leal 4(%esp),%eax; \
pushl_cfi %eax; \
movl PT_EDX(%eax),%ecx; \
movl PT_ECX(%eax),%edx; \
movl PT_EBX(%eax),%eax; \
call sys_##name; \
addl $4,%esp; \
CFI_ADJUST_CFA_OFFSET -4; \
ret; \
CFI_ENDPROC; \
ENDPROC(ptregs_##name)
...
PTREGSCALL3(execve)

因此，為了修改sys_execve我需要替換其代碼而不修改其地址？ 我在這里讀過類似的東西 ，這是走的路嗎？

更新＃2

實際上，我發現了以下調用序列： do_execve->do_execve_common->search_binary_handler->security_bprm_check ，並且此security_bprm_check是LSM（Linux安全模塊）操作的包裝，該操作控制二進制文件的執行。 之后，我閱讀並遵循了此鏈接，然后我開始工作了。 它解決了我的問題，因為現在我可以看到要執行的進程的名稱，但是我仍然不確定它的正確性。 也許其他人會為所有這些東西增加一些清晰度。

Answer 1

過去，在Linux內核中掛接syscall是一個比較容易的任務，但是，在較新的內核中，程序集存根已添加到syscall中。 為了解決此問題，我即時修補了內核的內存。

您可以在此處查看我的用於掛接sys_execve的完整解決方案： https : //github.com/kfiros/execmon