BPF and kprobe hooks may stop yielding to ftrace kill switch

Writing zero to kernel.ftrace_enabled has long been able to silence BPF trampolines (fentry/fexit) and ftrace-based kprobes without error: attach still succeeds, the hooks simply stop firing, and turning the knob back on restores them as quietly as they vanished. Andrey Grodzovsky has posted an RFC series on the BPF list that would close that gap the same way livepatch already protects itself, by marking the relevant ftrace ops permanent so the sysctl refuses to disable ftrace while they are registered and refuses new permanent attaches while ftrace is off.

For BPF trampolines the change restores behavior that existed until a 2022 per-trampoline ops split dropped the flag and never put it back. Classic ftrace kprobes and kretprobes never had the protection. Multi and session kprobes backed by fprobes are left out for now, because return-capturing fprobes share infrastructure with unrelated tracers and cannot take a blanket permanent flag.

Jiri Olsa acked the trampoline side. Steven Rostedt went further: the sysctl was a safety kill switch from ftrace's early, riskier days, and he would rather deprecate it than keep special-casing consumers around it, perhaps turning the write into a no-op with a loud notice so anyone who still depends on it can speak up. Grodzovsky said he would prefer that path if the community agrees, since it would also cover the fprobe cases the RFC cannot.

Linus Torvalds, brought into the thread, restated the usual bar. User-visible knobs can change if real workloads do not regress; the risk is wasted effort and a forced revert, not a categorical ban. Any change should fail obviously in userspace rather than only via a kernel log line most operators never read. Whether the permanent-ops fix ships, the kill switch is retired, or both, the practical stake is the same: monitoring and security tooling that rely on these hooks should no longer be able to go dark because someone flipped a global ftrace switch.