From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f50.google.com (mail-wr1-f50.google.com [209.85.221.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 86C083F164A for ; Mon, 11 May 2026 13:49:27 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.50 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778507369; cv=none; b=coL0vZDABKNTfGq2e4C8SpRZKBrUQBo/CKOqGEKQJfA2oey/tM2s7LouyzCU58SR2FmpjgCOE1xFBvJ1v4ptCDb0cYgU/RduFajKJk3Nf41BsVTbl1uC7P4yFhdIN88Lu3MH9dvus6l3swiGvJ4CAgcIRr1w+mhxUdDNAv+PfeY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778507369; c=relaxed/simple; bh=7ZUKOz2Tx9obpiEaBnPx2HLjlEm6lGU6cxX8h89V1hg=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=K6/LmfS5SeAi9t1ZfrRfF5Pf3P6Su7WaqXQa6efgBQR3fzdEgbhiR0ZjFEX9oY6gXgZ8cj/Uz1bFf/+/PWf5B1fro4DMPz+FAYtrbnwvJna4bYsmDZDdXTSK0DNmnlVaeFlWlYzEytZMRl4Z+0nr2p4HFOBfDcVuEydZ1uk5vo8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com; spf=pass smtp.mailfrom=suse.com; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b=MQgh6f5z; arc=none smtp.client-ip=209.85.221.50 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=suse.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b="MQgh6f5z" Received: by mail-wr1-f50.google.com with SMTP id ffacd0b85a97d-43fe62837baso2232457f8f.3 for ; Mon, 11 May 2026 06:49:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1778507366; x=1779112166; darn=vger.kernel.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=SCQ8Pz9y9YmgscDZb6MkYXZ00mYkeK75zPxgqibVrmc=; b=MQgh6f5zw/gLRtHd/yDZawXr87t2SrR7t3V+slf0AwqXXc16h6wvNWBqSUS1dRR3B2 Pq4QGqWfeOPy1cprqT9T+nwu9MMl6YKFFQa5jFdJq0l0IFjh0fiC8TVlN5cbzIKFn94m iLhj09+pMiHJiKuJ3qoQSucqzVGcpPQaBmo0PXuoaIhq92Pto5JtEg9EgznR15bHnSOZ VxYLQqgJJt61EOrgnvH0UZ53gmz1SGaNemohE26d3tf8aqDG/1Ayzk2yIr1xUBSTz7CL OQKOu79F2GGsw6EXQLfSdMwtngAyj6EwfKmDFS+6YOwEwqe3zHUqKizGIQuKEeN/ZE4U zH0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1778507366; x=1779112166; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=SCQ8Pz9y9YmgscDZb6MkYXZ00mYkeK75zPxgqibVrmc=; b=EwHYriG5bLsazjQoyipymgRkK9W+uNYPoU9vmn2noKPBN6n+FpPA7zKs8c5lX1q1dn +ElEpncD4nSNDh6Dtg6yAFj+HMge/0VnUhtM1li3ihT47/C/2RUEUUGWF3GIi1CiXCH2 6PZ7G7PeVtyveBsjzADVKXrwJvcyLuTQosjUiPQJLuppTub+mwoz9qdQIL2lr8rDNQmj 6NXfzbUf0YYIAmFltu+QzRse3FciSiJ/a7SHZxJ8tDkRQ4VB49NN1RvTcrXEj0289G+w Lz7yZD5xGOX0TIBP7sTxtF0RUUHRtz9YaZtlKyF8+87jUboAEXNy6s4pCG7vSuPo4Wdp epnA== X-Forwarded-Encrypted: i=1; AFNElJ/GGC9T47/0PMKb0792q2b2p8uCGJUrd3y2XE3kDKPI8ZaSyPjZh3+79jkRb8Z6vni2T8KQ1vzl26tCJJw=@vger.kernel.org X-Gm-Message-State: AOJu0Yxcv8BOEW+bSsdk5wqcmAIySfWyuUEIsjbpavow81N5z/utMpVe DtxyB80aGZ3nZqBii1xATYfUntkTmb87IPvm4SPRLmNaajjVEZwhquZUybS8krG+9mk= X-Gm-Gg: Acq92OHlojJBIT3jDWAaX96gRrWV/KizFVZT02eYZIZz43fpv223phz1qtTFmFar1k2 N3KEUkdxwZuERTcshuZUdcZ/jYHyH6Imc1egwgPtdbigYLJ0Sl7CbLtvp0juajXv3+WNWdScaO1 x2qVpxMzJN12ok/ELWSmwAECy0LoJrHLkEk/IpQ7fQcy5H7fXIZ7PZexKpEoZI0pmn/gunpVKox 3HWPuISrf2cpQzu86XxyOTrklfT46Y5opLE/5LWAHNglqv498ylexy4huVic72MSoyVWEg8cMRF csp9H3n0NRaVwIZhWkNBCIpgAyJ524miVOPN0XWbqH7NveJjYQzey8ljVi5hYoQGny99PZhUGW6 +WxWilbRy7pR5ZseXKwKNOVQzJCrhvWC/RRLiI+2b+PiGpgzafBgo6f33IEMiisPCBqJ9JuV/88 l2k+S+C1U3zbEk9T5Mh3xLZrpYlOonpE2RuCqX X-Received: by 2002:a05:6000:2995:20b0:43d:762e:76c6 with SMTP id ffacd0b85a97d-4515b05738bmr29206378f8f.7.1778507365866; Mon, 11 May 2026 06:49:25 -0700 (PDT) Received: from localhost (109-81-87-110.rct.o2.cz. [109.81.87.110]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-45491e94c0fsm26646490f8f.32.2026.05.11.06.49.25 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 11 May 2026 06:49:25 -0700 (PDT) Date: Mon, 11 May 2026 15:49:24 +0200 From: Michal Hocko To: Sasha Levin Cc: Breno Leitao , Andrew Morton , corbet@lwn.net, skhan@linuxfoundation.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, gregkh@linuxfoundation.org Subject: Re: [PATCH] killswitch: add per-function short-circuit mitigation primitive Message-ID: References: <20260507070547.2268452-1-sashal@kernel.org> <20260508135630.a380e3c187b59e4c04e6f358@linux-foundation.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: 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 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