From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f43.google.com (mail-wm1-f43.google.com [209.85.128.43]) (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 B90D442B75D for ; Mon, 11 May 2026 16:10:23 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.43 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778515825; cv=none; b=ZFXgl4AL62cxFqM7HQ4Xvra6a7gkWViQm7QARZ0g4HikHzeg3M8Aj9H1piflvdkWwIprANVJPVYAx9Q8izhGOPF+xXZoYBWG5rZ8CFD+Fg6dn+8RIfr+60+n8PlQRYbJM5jK+AXy3MXxv8KYuMRiXTAxEdjVTZ+iGwrBpvKElMw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778515825; c=relaxed/simple; bh=OmvtPFStqV16YJcLxeDtexAgfQAtOiiq7qfNn3U/6xI=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=AQUhm6c9c5kVKajx6ftj3pchWsujktUEWPhCw9M4twBCt3n7OzUMYuAUjF8rzM9VrPi8uCnZrK069OXm0oxo8BXOap+bNfN+Y42AeoNqalEPVZAmqTckfDD9gL3R6Da+/YIxiV61TB0zOF+dW6PfjElCQr1MyqE4Cw+RoBZCUb4= 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=BO4d5rk1; arc=none smtp.client-ip=209.85.128.43 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="BO4d5rk1" Received: by mail-wm1-f43.google.com with SMTP id 5b1f17b1804b1-4891c00e7aeso38422395e9.2 for ; Mon, 11 May 2026 09:10:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1778515822; x=1779120622; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=OQS2pqCl4CIffFZYG4lF0Zb7HM0F6Dphiww0tGWvLbM=; b=BO4d5rk1MeYPDxmoKxd3BVxwNwZoDHaUmBxmM34dERnhRpcwRJvHXAdxUgsvN44axx zdg85Dnv8bKwtz0j0hGxvSY+7tWXqghVrsiHif64QNeOBrusxHWzhQ2H5eU7iYdpn0N+ 8qZuMOm00YrI6mWNi5cpLC8/8CGzJ4k3Y7gnWy0MRBeybFsMguosxN+08Ed8rxtKpeq8 RmNDdu9lb3iMakktHPhIpGw1JDBeiFb85gaOWD/Tk3YIPQiDM7CTha1qTi7fn3L1njE1 qQ3y/VeCTwtgaYAB+3eN8QWi1lQXyxbEMW3cWuYo9yy2ym2E4feCIokzBmf5oguvCjj4 SVYw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1778515822; x=1779120622; h=in-reply-to: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=OQS2pqCl4CIffFZYG4lF0Zb7HM0F6Dphiww0tGWvLbM=; b=eZam6dskqfzxPnHaUY6KXEbZqhO3MO1im/RKeIzA1Kg+lC1YcxpNlku+MecuvdLwI6 8ORA2/Gte6VsSE/Er9BjIflu56HW2pRs63NIiRMNvE8fGOB6UdsZ5NIMYcMSLZORuD+s lm6Gb5bX/XA3kVj2Qa90st8i2mD6SZvmqCnNkMwF+x6JuQgupDX6A06I8us4lQGuIs9Q qtAOiWCl/pAZqyOu6fYz+tA1P/4NwMuPNtbOi7FsqGpl/vKhfBX9TiCi+l16s9CpXzzT Hq7azxqsQKeTmK8bezV2i6Q5sAXwBWhta+SENY+1DHuJlpIMO8RFcsB7yuWCUJOwucIV bv5w== X-Forwarded-Encrypted: i=1; AFNElJ8QqGNNcLhYdeQhWAmiDj0e3uK5lTzgTn15K6EeaG1YiyOD1Avs3xPLlNrRkHpkUYPRH0XuMof8WtSL3kc=@vger.kernel.org X-Gm-Message-State: AOJu0Yy21VHDSx1DihNTw1daGt18Heei2ssrq47qyU2ya49akuiXpphu ylm9n/mjsF5TWsO6UMLCQSZadHCzmikHGZZnRmVMyi/ix8cbKoG5iY+CVxkT6TxKqSk= X-Gm-Gg: Acq92OFGed4I/yXOS/QfxtN5M50kvU0NwwyizmLhd71bdc9qjRalF/srJnp4ftzK6EI Ryh2jFBuDextVZ6TEyirMLQqeiCwfc5Dla+2me3YQMY4NlSJwbNpiAUYrv6n43u58O5E28SUZZX pkDrWJMzb0OQkI2iCsmEAbILospFsa8KX99SO03bhW3Fn3YrMelXnHo+bjWzTW2AP6MNvJMuyoj xXiGMKX01rpTAY4vfJCud9/sji7D0cIDEEdjioTJj2nSimunOBIpq6SUNN/Apq6PeNguUdU6ucN /Do8F1i860YqoKGYDoZ5U920wUd2tH607r45Sr6Uin8UPnBuMSSZEg38rWZLYuHjEPw2IMPxHd5 /0WlKWSqa3zNdZbv/9D7xaq3bZ+F/f0aDJKL0CwIKFOKgVcMtWcHBuoz2QmQZWktRzw/usTnKMj dCutbstq5ZLkGfm13imBGPPiZf9bmJnNRg/ByaSALYZ+gnJ8o= X-Received: by 2002:a05:600d:1:b0:48e:7f1c:8760 with SMTP id 5b1f17b1804b1-48e7f1c87bdmr94074745e9.27.1778515822123; Mon, 11 May 2026 09:10:22 -0700 (PDT) Received: from localhost (109-81-87-110.rct.o2.cz. [109.81.87.110]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-48e702e0c70sm214374865e9.6.2026.05.11.09.10.21 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 11 May 2026 09:10:21 -0700 (PDT) Date: Mon, 11 May 2026 18:10:20 +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=us-ascii Content-Disposition: inline In-Reply-To: On Mon 11-05-26 11:55:41, Sasha Levin wrote: > On Mon, May 11, 2026 at 04:25:57PM +0200, Michal Hocko wrote: > > On Mon 11-05-26 09:56:30, Sasha Levin wrote: > > > On Mon, May 11, 2026 at 03:49:24PM +0200, Michal Hocko wrote: > > > > On Mon 11-05-26 09:39:32, Sasha Levin wrote: > > > > > On Mon, May 11, 2026 at 03:07:51PM +0200, Michal Hocko wrote: > > > > > 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. > > > > > > Safety checks like making sure the patched function is on the stack, or did you > > > mean something else? > > > > Yes, exactly what LP infrastructure already provides. > > But do we actually need it here? If not then you can simply systemtap or use BPF to inject the code. In other words we have several ways how to runtime modify the kernel so before yet another interface is provided (with a non-trivial amount of code and very limited functionality) you should really start by describing why none of the existing one is fitting well. I do understand your argument that solutions based on loading a module might have an additional step to deal with (AFAIK you do not need to build your own kernel to deploy your key) is that a brohibitive roadblock? We also do have fault injection which is much less convenient because of all the existing constraines but can those be elevated? So nothing really against playing with ideas nad LLMs to generated a quick PoC. That is all good but for this to be considered more seriously I think we really need to think deeper whether the existing infrastructure is really not fitting and if not whether it could be changed to cover more usecase like the one you have mentioned here and I believe it is something worth thinking about. -- Michal Hocko SUSE Labs