Kernel Runtime Security Instrumentation

### Overview In this presentation, KP Singh from Google's detection and response team in Switzerland introduces Kernel Runtime Security Instrumentation (KRSI), an eBPF-based security prototype designed for Linux. The primary motivation behind KRSI is unifying two fundamental aspects of security: signaling (auditing indicators of potentially malicious activity) and mitigation (preventing harm based on detected signals). Currently, signaling and mitigation in Linux are often disjoint—auditing changes require modifying audit subsystem policies and pipelines, while mitigations require updating LSMs (such as SELinux or AppArmor) or seccomp, leaving defenders one step behind threats.

### Key Topics - **Unified Signaling and Mitigation:** Integrating telemetry generation and runtime mitigation within a single API rather than maintaining disjoint subsystems. - **LSM-Based Instrumentation:** Focusing instrumentation on security behaviors rather than syscall entry points, leveraging Linux Security Module (LSM) hooks as funnels for behavior. - **Granular eBPF Helpers:** Moving away from broad tracing helpers (like `bpf_probe_read`) to avoid unstable dependencies on internal kernel data structures and maintain large-scale backward compatibility. - **Alternatives Analysis:** Evaluating KRSI against existing mechanisms including audit, seccomp, kprobes, and Landlock. - **Prototype Case Study & Performance:** Examining an environment variable auditing prototype and assessing latency overhead.

### Technical Details KRSI introduces a security-focused eBPF program type attached directly to LSM hooks represented in sysfs. Instead of attaching to tracing or socket hooks, KRSI hooks capture higher-level security behaviors. For instance, while process execution can occur through multiple syscalls (e.g., `execve`, `execveat`), an LSM hook funnels these into a single behavioral interception point. Userspace utilities (such as a daemon or agent) load and attach BPF programs via file descriptors (`BPF_ATTACH_MULTI` model), using buffers (such as the perf ring buffer via `bpf_perf_event_output`) to ship audit events to detection pipelines.

To keep helpers backward-compatible and maintainable, KRSI avoids broad memory reads that require templating against kernel headers. Instead, it introduces precise, granular helpers tailored to specific security requirements, such as targeting specific environment variables like `LD_PRELOAD` instead of dumping all environment pages (which can span up to 32 pages under `linux_binprm`).

Benchmarking a no-op binary executed 100 times across multiple iterations showed a baseline peak around 517 microseconds. Enabling standard audit with `execve` tracking resulted in higher and less predictable latency, whereas the KRSI prototype logged environment variables and process metadata (TGID, PID, UID) with modest overhead (peaking around 533 microseconds).

### Open Questions & Discussion Several design challenges and community topics were discussed: - **Event Buffering:** Evaluating whether perf ring buffers should be retained (considering per-CPU vs. shared buffer synchronization overhead) or replaced. - **Sleepable eBPF:** Addressing whether eBPF should be allowed to sleep to simplify accessing user-space memory, avoiding workarounds such as LSM hook pre-computation. - **ABI Stability & Landlock Comparison:** Audience members noted ongoing discussions regarding LSM API stability, userland ABI exposure, and parallels to Landlock.

### Takeaways KRSI demonstrates that eBPF attached to LSM hooks can provide flexible, granular, and dynamic security instrumentation across workstations and data centers. By decoupling policy updates from kernel rebuilds and providing low-overhead behavioral monitoring, KRSI bridges the gap between fast threat detection and dynamic mitigation in Linux.