On Fri, Apr 3, 2026 at 7:29 PM Steven Rostedt <[email protected]> wrote: > > On Fri, 03 Apr 2026 18:25:59 +0800 > Menglong Dong <[email protected]> wrote: > > > I think the security problem is a big issue. Image that we have a KLP > > in our environment. Any users can crash the kernel by hook a BPF > > program on it with the calling of bpf_override_write(). > > Right, livepatching may allow for rapid experimentation but that is not its > purpose. It is for fixing production systems without having to reboot. > Using BPF to change the return of a function is a huge security issue. > > > > > What's more, this is a little weird for me. If we allow to use > > bpf_override_return() > > for the kernel functions in a KLP, why not we allow it in a common kernel > > module, as KLP is a kind of kernel module. Then, why not we allow to > > use it for all the kernel functions? > > Right. > > > > > Can we mark the "bond_get_slave_hook" with ALLOW_ERROR_INJECTION() in > > your example? Then we can override its return directly. This is a more > > reasonable for me. With ALLOW_ERROR_INJECTION(), we are telling people that > > anyone can modify the return of this function safely. > > If this were to go in, I say it would require both a kernel config, with > a big warning about this being a security hole, and a kernel command line > option to enable it, so that people don't accidentally have it enabled in > their config. > > The command line should be something like: > > allow_bpf_to_rootkit_functions
The feature is currently gated by CONFIG_KPROBE_OVERRIDE_KLP_FUNC. In the next revision, I will rename this to CONFIG_ALLOW_BPF_TO_ROOTKIT_FUNCS and introduce a corresponding kernel command-line parameter, allow_bpf_to_rootkit_functions, to control it. -- Regards Yafang
