From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7D52C3E9C16; Thu, 21 May 2026 14:38:42 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779374323; cv=none; b=ZYGJl7wkYRyU/fEvkOBEF6oAi21Qe4zdvq+FP7d+P1P1ndyM+ofGsDT+kS7U6kudEyo7P/5uT09EtaXFdehjy6rJPVJU1gBA9WoEi2ydfB06q7+025YgFQ986IZDEUclI1t8v6g23nWu7G8+94KZGcT0OMXSwT4MI0l7jedYV8g= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779374323; c=relaxed/simple; bh=XK48jeRB+QfYua9qvT6nkgqWoyk74EnZmHziGEhJckQ=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=CZfb8BFFnQWOx+LsXHPZCYEUgQv1GPCMFU29vnJIV6n2ZViu3SEwJIoWiD2BkYG/pPcHKoi50zEvGLa2f5aw8XElXgLijJoAyYlPRIED/TAIx+0mP+diX9PD7Labmi+rLRXvytYw6xiY1jXVyHnUZXLNi+BmarduS2Tq6Yexh6E= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=XsBlQTOC; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="XsBlQTOC" Received: by smtp.kernel.org (Postfix) with ESMTPSA id EA3991F00A3B; Thu, 21 May 2026 14:38:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1779374322; bh=nTzgC5HjU2axc7qp/6EBnj55/XJGfG1tYASFCI0U7g0=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=XsBlQTOCK2YksJm2MNjyE7j0ny1HPTgDymFmsxNKKxr1BVdAvgPOBuNn6tFA7vGjg CSQXiV3VGsBWuWOwPes8pP8JUZc2AK1A75GOlY3qX2oC5FjQ7qoHn31pb8iXNfDSFm iXK2YnCBCaUWupOdSh0ZVPN+0hcaS9CE+UFVcZubluvtHYPOHE110zqo5nJZBbiaNl 07zGPmwKluAZrGdXdG5ILZLoarbkdL9yDRoeg2O+Yo3PYLyE8/2+NE9g1lJxASkcRS B6VRE8y+mpZLmBsjrXBLlPLTbSWjyT2Yslzd/guaonNwFYtLf41VMjJQhPrDfeUtxL sB6G0e3DI2Biw== Date: Thu, 21 May 2026 10:38:40 -0400 From: Sasha Levin To: Song Liu Cc: Daniel Borkmann , linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org, linux-kselftest@vger.kernel.org, bpf@vger.kernel.org, live-patching@vger.kernel.org, Greg Kroah-Hartman , Andrew Morton , Jonathan Corbet , Mathieu Desnoyers , Joshua Peisach , Florian Weimer , Breno Leitao , Anthony Iliopoulos , Michal Hocko , Jiri Olsa , John Fastabend , Christian Brauner Subject: Re: [PATCH v3] killswitch: add per-function short-circuit mitigation primitive Message-ID: References: <20260508195749.1885522-1-sashal@kernel.org> <20260517134858.146569-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-doc@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On Tue, May 19, 2026 at 03:00:15PM -0700, Song Liu wrote: >On Tue, May 19, 2026 at 12:57 PM Sasha Levin wrote: >[...] >> >Fully agree with Song here that there is no clear boundary, and that the >> >killswitch could lead to arbitrary, hard to debug breakage if applied to >> >the wrong function.. introducing worse bugs than the one being mitigated >> >or even /short-circuit LSM enforcement/ (engage security_file_open 0, >> >engage cap_capable 0, engage apparmor_* etc). >> >> This is similar to livepatch, right? Do we need guardrails there too? > >livepatch has the same guardrails as other kernel modules: >CONFIG_MODULE_SIG, CONFIG_MODULE_SIG_FORCE, etc. Which the user can choose to enable or disable. Livepatches will work just fine with CONFIG_MODULE_SIG=n, right? With the whitelist approach, the user has no choice but to accept it. Would it make sense to allow disabling the whitelist via a kernel config or some runtime flag? -- Thanks, Sasha