- An introduction to KProbes: KProbes is a debugging mechanism for the Linux kernel which can also be used for monitoring events inside a production system.
- JProbes are used to get access to a kernel function's arguments at runtime.
- Uprobe: http://www.brendangregg.com/blog/2015-06-28/linux-ftrace-uprobe.html
- Security Monitoring with eBPF
- Tracing syscalls using eBPF using tracepoints
- Syscall Auditing at Scale
- Linux kernel modules - security risk?
- Auditd: https://news.ycombinator.com/item?id=13010544 As the kind-of-sort-of maintainer of Linux's syscall infrastructure on x86, I have a public service announcement: the syscall auditing infrastructure is awful. It is inherently buggy in numerous ways. It hardcodes the number of arguments a syscall has incorrectly. It screws up compat handling. It doesn't robustly match entries to returns. It has an utterly broken approach to handling x32 syscalls. It has terrifying code that does bizarre things involving path names (!). It doesn't handle containerization sensibly at all. I wouldn't be at all surprised if it contains major root holes. And last, but certainly not least, it's eminently clear that no one stress tests it. If you really want to use it for production, invest the effort to fix it, please. (And cc me.) Otherwise do yourself a favor and stay away from it. Use the syscall tracing infrastructure instead. Yes, more or less. There are bunch of different "tracing" mechanisms in the kernel, and perf trace is the common way to use it. Syscalls trigger tracepoints, and anything that can see tracepoints can see them. Using eBPF to trace syscalls is probably quite useful.
-
Tracepoints (stable): https://www.kernel.org/doc/Documentation/trace/tracepoints.txt
-
kprobe (unstable): bpf