> 1. From what I've read in the DocBook pages I've figured out that I have > to have two report entries. One for syscall_entry and one for > syscall_exit. On syscall_entry I should use syscall_get_nr() and check > if this number is equal to __NR_socket and return UTRACE_SYSCALL_ABORT > in that case and on syscall_exit, I need to call syscall_rollback() to > rollback the registers if utrace_syscall_action(action) returns > UTRACE_SYSCALL_ABORT. Is this correct?
The report_syscall_entry hook is the only one you need to prevent the system call from running. If it returns UTRACE_SYSCALL_ABORT, then the system call will fail with the ENOSYS error code. You only need to use a report_syscall_exit hook if you want the registers the user process sees after attempting the system call to be different from that. > 2. First I've read the documentation from Roland's page and figured out > it's out of date. report_syscall_entry callback used to have a struct > task_struct argument but now it doesn't. How should I get a "struct > task_struct" to pass to syscall_get_nr? Am I supposed to keep a > reference to the "struct pid" I used in init_module() and use > pid_task(pid, PIDTYPE_PID) or should I use find_get_pid() just as I used > in the init_module()? Those callbacks are made in the affected thread itself. So you can just use the magic variable 'current'. I've updated the web copy of the documentation. If you install the kernel-doc rpm on a Fedora system, that contains the version of this same documentation that goes with the kernel you have. > 3. In the report_syscall_exit callback, is the "struct pt_regs" argument > there so that the user can directly pass it to syscall_rollback() or do > I have to save the registers I had in report_syscall_entry() callback > and use them instead? You can just pass that pointer directly. In fact, the same pointer to 'struct pt_regs' will be passed to both callbacks. This is always the same pointer that 'task_pt_regs(current)' would return, just made quicker to access by having the argument to the callbacks. > 4. __NR_socket is available on some architectures and it's implemented > on top of __NR_socketcall on others. I'm running this example on x86_64. > How should my module figure out which mode the target process is running > in? I suppose this is related to the CS register. There are several ways to go about this, depending on how arch-specific you want to make it. On x86-64 it's possible for 32-bit processes to make 64-bit system calls and vice versa, though normal user programs will never actually do this. Perhaps the easiest and cleanest way, that both covers this arcane possibility and also works on other architectures, is to call is_compat_task() (under #ifdef CONFIG_COMPAT). > Having figured that how am I supposed to include system call numbers from > both architectures and use __NR_socketcall for 32bit mode and __NR_socket > for 64bit? Unfortunately, there is no clean way to refer to the 32-bit syscall numbers in code inside the 64-bit kernel. socketcall is not one of the few listed in asm/ia32_unistd.h, so off hand I think you'd just have to hard-code the i386 __NR_socketcall value in your module. > 5. Is there any project in the outer-space that does something like > this, sandboxing or monitoring system calls, from which I can learn > more? Renzo Davoli's umview/kmview is just such an animal. See http://wiki.virtualsquare.org for details. Thanks, Roland
