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

[Michal Hocko <mhocko@suse.com>]

On Mon 11-05-26 04:41:38, Breno Leitao wrote:
> 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.

LP is certainly a more laborous solution. I guess this is quite clear.
It is also much safer option as it deals with all implementation details
like consistency. All that is not done for fun. I am really wondering
how admins are expected to a) know which kernel functions are ok/safe to
disable and b) when it is safe to do so without introducing unsafe
kernel state or introduce an outright bug that way.

Thiking about this I can see how waiting for an official LP can be time
consuming and sometimes creating those is far from trivial. But would it
make sense to have automated LP creation tooling available that would
allow to return early from a function and relly on the existing
infrastructure to do the right thing?
-- 
Michal Hocko
SUSE Labs