On Mon 11-05-26 09:39:32, Sasha Levin wrote: > On Mon, May 11, 2026 at 03:07:51PM +0200, Michal Hocko wrote: > > 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 <[email protected]> > > > > > 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. > > Thanks for the feedback! > > > > 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. > > In a similar way to how they would know if a given livepatch is safe to apply > - > ideally it would be communicated by the vendor/distro/kernel team.
You have missed my point. KLP takes an extra steps to make sure patching a particular function is safe to modify or to put the change into the effect. > "On Debian XX.YY, use the following command to mitigate CVE-AAAA-BBBB: > > echo "engage woops -1" > /sys/kernel/security/killswitch/control" > > > 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? > > This would definitely help (and in light of how the last couple of weeks > played > out, the case for livepatches definitely increased), but not all > vendors/distros provide livepatches. The point I've tried to make is that you (as an admin) shouldn't depend on your vendor to provide you with an official LP just to disable a certain function(ality). That is/should be a trivial case where the LP should be ideally generated automagically if you have a tooling available. I might be wrong and overlook some complexity here. -- Michal Hocko SUSE Labs
