Re: [PATCH v3] killswitch: add per-function short-circuit mitigation primitive

On 5/19/26 1:59 AM, Song Liu wrote:
> 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).

Fully agree with Song here that there is no clear boundary, and that the
killswitch could lead to arbitrary, hard to debug breakage if applied to
the wrong function.. introducing worse bugs than the one being mitigated
or even /short-circuit LSM enforcement/ (engage security_file_open 0,
engage cap_capable 0, engage apparmor_* etc).

The ALLOW_ERROR_INJECTION() provides a curated white-list where you may
return with an error without causing more severe damage (assuming the
error handling code is right). The right thing would be to more widely
apply ALLOW_ERROR_INJECTION() or to figure out a better way to safely
enable the latter without explicit function annotation.

Wrt BPF:

>>>> * 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.

The claim that BPF itself is off in many production kernels is not really
true, where did you get that from? All the major distros and cloud providers
have BPF enabled these days, and even systemd ships BPF programs for
custom service firewalling etc.

The operator interface is to load a program vs. one-line write.. so we're
disregarding existing infra where you can already achieve the same for a
less safe one-liner convenience? (similarly for the livepatch infra..)

If you need a one-liner: bpftrace -e 'kprobe:FUNC { override(RETVAL); }'
Alternatively, add an extension to systemd where you can just deploy a
list of functions, and it does the necessary work in the background and
persistently.

Also, what about other classes of bugs, like OOB access, UAFs, locking
issues, etc which then could be used as a means for privilege escalations?
It feels like this proposal is a quick'n'dirty prototype via Claude as a
reaction to copy fail bug, but the right solution would be to improve
the user space tooling as mentioned and existing infra we have in kernel.