This fixes a long-standing issue: kernel.ftrace_enabled=0 silently
disables BPF trampolines (fentry/fexit) and ftrace-based
kprobes/kretprobes. The write succeeds, the hook stops firing with no
error, and re-enabling silently restores it.
The solution chosen is to deny setting this knob to 0 from userspace,
thus preventing this case in the first place. Steven mentioned that the
switch became effectively useless and doesn't serve any meaningful
purpose anymore, and only creates problems for systems that rely on
ftrace, such as Livepatching and eBPF. Any attempt to set it to 0 will
fail with -EOPNOTSUPP. Reading and writing 1 remain unchanged.
Patch 1: the sysctl change plus a doc note.
Patch 2: updates the one selftest that relied on the old disable
behavior.
This replaces an earlier attempt[1] to restore FTRACE_OPS_FL_PERMANENT
on BPF trampolines and classic kprobes to work around the same issue.
Steven suggested this simpler approach instead: rather than
tracking down every caller that needs protecting, refuse to disable
ftrace via the sysctl unconditionally.
The original patch-set was a fix to commit 00963a2e75a8 ("bpf: Support
bpf_trampoline on functions with IPMODIFY (e.g. livepatch)"), and so we
would want to see this backported at least to LTS branches starting
with 6.1. But since this is effectively a new behavior and technically not a bug
fix, I am not sure what the policy is in this case.
[1]
https://lore.kernel.org/bpf/[email protected]/
Andrey Grodzovsky (2):
ftrace: deprecate disabling via ftrace_enabled sysctl
selftests/livepatch: update test-ftrace.sh for deprecated
ftrace_enabled
Documentation/trace/ftrace.rst | 5 ++
kernel/trace/ftrace.c | 19 +++----
.../selftests/livepatch/test-ftrace.sh | 49 ++-----------------
3 files changed, 16 insertions(+), 57 deletions(-)
--
2.34.1
