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

[Breno Leitao <leitao@debian.org>]

On Fri, May 08, 2026 at 05:47:04PM -0400, Sasha Levin wrote:
> On Fri, May 08, 2026 at 01:56:30PM -0700, Andrew Morton wrote:
> > On Thu,  7 May 2026 03:05:45 -0400 Sasha Levin <sashal@kernel.org> wrote:
> >
> > > When a (security) issue goes public, fleets stay exposed until a patched kernel
> > > is built, distributed, and rebooted into.
> > >
> > > For many such issues the simplest mitigation is to stop calling the buggy
> > > function. Killswitch provides that. An admin writes:
> > >
> > >     echo "engage af_alg_sendmsg -1" \
> > >         > /sys/kernel/security/killswitch/control
> >
> > It certainly sounds useful, but what would I know.  How do we hunt down
> > suitable operations people (aka "target audience") to find out how
> > useful this is to them?
>
> I'm not entierly sure here... If folks have suggestions on folks to loop in,
> that'll be great!

I work with these issues at Meta, and this approach would address a real
need we have.

While livepatch could theoretically solve this problem, it's less suited
for rapid mitigation for a couple of reasons:

1) Livepatch rollout is inherently slower due to the blast radius if a
   bug exists in the livepatch mechanism itself.

2) It's common to run hundreds of different kernel versions across a
   fleet. Since livepatch is kernel-specific, a single CVE suddenly
   requires building and deploying hundreds of individual livepatches—
   far less practical than a simple sysfs write.