All of lore.kernel.org
 help / color / mirror / Atom feed
From: Anthony Iliopoulos <ailiop@suse.com>
To: Sasha Levin <sashal@kernel.org>
Cc: Florian Weimer <fw@deneb.enyo.de>,
	corbet@lwn.net, akpm@linux-foundation.org,
	skhan@linuxfoundation.org, linux-doc@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org,
	gregkh@linuxfoundation.org
Subject: Re: [PATCH v2] killswitch: add per-function short-circuit mitigation primitive
Date: Mon, 11 May 2026 12:33:28 +0200	[thread overview]
Message-ID: <agGweC12aloH8DBq@foo> (raw)
In-Reply-To: <af8pw54Y-Q18kSR0@laps>

On Sat, May 09, 2026 at 08:34:11AM -0400, Sasha Levin wrote:
> On Sat, May 09, 2026 at 02:02:24PM +0200, Florian Weimer wrote:
> > * Sasha Levin:
> > 
> > > When a kernel (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
> > > 
> > > After this, af_alg_sendmsg() returns -EPERM on every call without
> > > running its body. The mitigation takes effect immediately, and is dropped on
> > > the next reboot -- by which point a patched kernel is hopefully in place.
> > 
> > Do you expect this to be safe to enable in kernel lockdown mode (i.e.,
> > with typical Secure Boot configurations in distributions)?
> 
> Yes: under lockdown, killswitch has to be configured on the cmdline. Runtime
> engage is gated on the new LOCKDOWN_KILLSWITCH reason.

Basically this proposal allows for any function to be overridden on a
production kernel as long as no lockdown level is enabled, which is quite
dangerous.

Assuming this is acceptable (which I am not sure it should be), then this
is equivalent to the existing error injection code that we already have in
the kernel (CONFIG_FAIL_FUNCTION) minus the explicit whitelisting on a per
function basis required to permit injection.

Given that this achieves the exact same result, then why don't we consider
simply removing the whitelisting restriction from fail_function altogether
and use that instead? The only thing missing then would be the boot param
parsing and setup.

This way we'll be removing a few hundred lines of code instead of adding
more duplication, while enabling the same functionality.

[As a bonus, this would also make the existing framework more practical to
 use for testing arbitrary function failures. I have been carrying a debug
 only patch to that effect for a while, which basically just shorts the
 whitelisting check when CONFIG_FUNCTION_ERROR_INJECTION_ALLOW_ALL=y.]

Regards,
Anthony

  reply	other threads:[~2026-05-11 10:33 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-08 19:57 [PATCH v2] killswitch: add per-function short-circuit mitigation primitive Sasha Levin
2026-05-09 12:02 ` Florian Weimer
2026-05-09 12:34   ` Sasha Levin
2026-05-11 10:33     ` Anthony Iliopoulos [this message]
2026-05-11 11:15       ` Sasha Levin
2026-05-11 17:23         ` Anthony Iliopoulos
2026-05-11 20:12           ` Sasha Levin
2026-05-11 13:14 ` Breno Leitao
2026-05-11 13:41   ` Sasha Levin
2026-05-11 14:59     ` Breno Leitao

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=agGweC12aloH8DBq@foo \
    --to=ailiop@suse.com \
    --cc=akpm@linux-foundation.org \
    --cc=corbet@lwn.net \
    --cc=fw@deneb.enyo.de \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=sashal@kernel.org \
    --cc=skhan@linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.