On Mon, May 18, 2026 at 6:33 AM Sasha Levin <[email protected]> wrote: > > On Sun, May 17, 2026 at 11:37:36PM -0700, Song Liu wrote: > >On Sun, May 17, 2026 at 6:49 AM Sasha Levin <[email protected]> wrote: > >> * fail_function (CONFIG_FUNCTION_ERROR_INJECTION) is disabled in > >> most production kernels. Even where enabled, it only works on > >> functions pre-annotated with ALLOW_ERROR_INJECTION() in source - > >> no help for a freshly-disclosed CVE. The debugfs UI is blocked by > >> lockdown=integrity and the override is probabilistic. > >> > >> * BPF override (bpf_override_return) honors the same > >> ALLOW_ERROR_INJECTION() whitelist, and BPF itself is off in many > >> production kernels. Even where on, the operator interface is > >> "load a verified BPF program," not a one-line write. > > > >If it is OK for killswitch to attach to any kernel functions, do we still > >need ALLOW_ERROR_INJECTION() for fail_function and BPF > >override? Shall we instead also allow fail_function and BPF override > >to attach to any kernel functions? > > I don't think so. ALLOW_ERROR_INJECTION is not a security mechanism, it's an > integrity/safety mechanism for both bpf and fault injection. > > It protects against a "developer or CI script doing legitimate fault injection > accidentally panics the box" scenario, not an "attacker gets in" one.
There really isn't a clear boundary between "security mechanism" and "non-security mechanism". As we are making killswitch available everywhere under root, users will soon learn to use it to do fault injection, and potentially much more scary things. (Think about agents with sudo access). Thanks, Song
