Session

system call hooks are often used to offer an alternate kernel function instead of currently running host kernel. by running arbitrary programs at the hooks, regular syscall invocations are not going to the host kernel, but into the appended code instead. kernel emulators (user mode linux, or gvisor) needs such mechanisms to replace the behaviors, or RDMA library to offer socket-like API by replacing syscall-related symbols to redirect the call path to its own implementation.

the feature of syscall hooks is historically used to monitor, or control userspace application programs from outside of the process, with a dedicated program to inspect and even change the behavior of the target program. later on, dependency to the external controller is eliminated and replacing the original syscall became also possible (i.e., by using LD_PRELOAD, or rewriting binary files on the fly). By applying the syscall hooks, users can benefit existing application programs on the emulated kernel without rewriting the application programs.

But there are still issues to achieve 1) low overhead, and 2) complete hook ability.

in this talk, we will look back the history of this syscall hook feature, how the function has been improved, what is still a problem, and how we can move forward in future. we will also discuss observed/well-known limitations of running applications with syscall hooks, while benefiting running unmodified application programs.