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 2A05B3FF1AB; Tue, 26 May 2026 14:29:45 +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=1779805787; cv=none; b=AUc5MNpjfYJLd9hFWghdGyk54Ry0pxtYN4CLMwfXQ56mLdFKOSrU81ME70q3qMDpc3R5RwvbJh3BTNo3iCIxb486dS3kJQtsuWKYQX24pIUocgxs0k2Kgij5ULalyfjHg1VI+P4azaIuZ9Q2FADLWEH9eduU3FU5Ih79+n1TcIw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779805787; c=relaxed/simple; bh=01QZ3Oc+k3R391wthpsoqAJ4A4j9P7bKR8UG9T3xXXo=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=GKJewTHD96pW9neIFhdR92mobyLjNtcTYZSdmdGQSY4pAFXP+l6pBsQmpd+IrTIYWkFYWa7ivmjlQfpSYYArIvLuCz0VhDrYBERngxlUpUGDjDnGHMfBZSvHryFg6PXuS7RLoq0VXEfqQfrlCVtI1n3yuvcdOLkUbtfQXa4tymA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=EzsWz/vl; 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="EzsWz/vl" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 76D741F000E9; Tue, 26 May 2026 14:29:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1779805785; bh=GSX/o3tGKH8prhZQKAGSjMb4rUlV/Z55PxckME59z4U=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=EzsWz/vlNWJNW+NMA+grSpGmEAlzW1dMhzljG4DDGQOP42grQ3eEtdXE+yg/tu0nJ e2v3LjX3uBcVx2JXnnVCBQNmCVQI7uLKvZgmd7Nxrd6B+jZBk85BEhu6L9hr4AWOhN DmVXv8lzXWvF/wiKNTotwFW8EP7Ra+ZA35C0sV8SMVdKBC9j5ntx1+ijctMD6qQYF9 3qUB2mKBtFBdFI85Oqtg3YjaU1gaQYfEjc1plhfWPXZUkEMZg3O4ZfPw+YIn8ZesD3 5FkFfGfwX6V0F/bhrOcnpOSpiV6QT7FJQ6li+thvYCff9a1ujIZiIrS55YWerf7k2a Zd7p7PpJbHEkA== Date: Tue, 26 May 2026 10:29:44 -0400 From: Sasha Levin To: Daniel Borkmann Cc: Song Liu , 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 , KP Singh Subject: Re: [PATCH v3] killswitch: add per-function short-circuit mitigation primitive Message-ID: References: <3dd6d852-18fb-4c64-a1ae-0d79ef7c061f@iogearbox.net> 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 26, 2026 at 03:10:45PM +0200, Daniel Borkmann wrote: >On 5/23/26 3:41 PM, Sasha Levin wrote: >>On Thu, May 21, 2026 at 11:16:46AM -0700, Song Liu wrote: >>>On Thu, May 21, 2026 at 8:31 AM Sasha Levin wrote: >>>>On Thu, May 21, 2026 at 11:11:16AM +0200, Daniel Borkmann wrote: >>>>>On 5/19/26 9:57 PM, Sasha Levin wrote: >>>>>>Sure, this would also work. How do you see this happening? Can we let a certain >>>>>>user/pid/etc disable the allowlist if they choose to? >>>>> >>>>>I don't think we should, given then we're back to square one where root >>>>>or some other user would be able to just override/bypass an LSM. >>>> >>>>killswitch already disables itself when lockdown is active. We can easily >>>>disable it too when one of the LSMs that cares about this is active. >>>> >>>>>[...] >>>>>>How do you see this working with the allowlist? >>>>> >>>>>We should look at the underlying areas where most of the CVE-like fixes >>>>>took place (these days should be more easily doable given Claude and friends) >>>>>and based on that either extend ALLOW_ERROR_INJECTION() or (better) create >>>>>new hooks which BPF LSM can consume where you can then have a policy to reject >>>>>requests and tighten the attack surface. For example, the AF_ALG stuff you >>>> >>>>So we could grow the LSM tentacles deeper into the kernel, and we can see where >>>>current CVEs are happening, which I suspect is the darker corners of the kernel >>>>(old unmaintained, rarely used code), but this definitely won't stay the case, >>>>right? Newer and better LLMs will discover issues elsewhere, and once the low >>>>hanging fruits are picked off of the current target subsystems, researchers >>>>will move elsewhere. We will be dooming ourselves to an endless cat and mouse >>>>game where we go add LSM hooks after some big security issue goes public. >>> >>>Do we really need to add new LSM hooks for recent CVEs? >>> >>>The LSM hooks are designed to cover all the user-kernel interfaces. Then >>>with properly designed policies, we should have coverage for potential CVEs. >>>Existing LSM hooks may not be perfect, but we can improve the hooks, >>>potentially with the help of smart LLMs, so that these hooks can cover >>>future security issues. In some cases, we will need new policies, but I don't >>>think new hooks will be needed for most of these CVEs. >> >>Running a quick LLM evaluation on the last ~70 severe CVEs, it seems that about >>40% is doable with the current hooks. > > >Interesting, do you have some more details in which areas your eval sees new >lsm hooks missing? The recent ones I saw fall into about 5 buckets: 1. Kernel-thread / workqueue context: LSM hooks fire but current is a worker, not the actual attacker. Lots of ksmbd, ceph-msgr, and async cleanup races land here. 2. Driver: pci_driver.probe, notifier_call_chain, ib_* RDMA callbacks, ndo_*, bus dispatch tables all sit below any LSM hook. Big chunk of mlx5, RDMA, USB, i3c, DRM bugs. 3. Per-packet softirq RX: security_sock_rcv_skb only fires inside sk_filter_trim_cap, which UDP encap_rcv bypasses and L2/bridge protocols never reach. Covers Bluetooth softirq, bond, IPv6 softirq, TCP-MD5/AO timing leaks, etc. 4. Netfilter: config path is well-gated via security_netlink_send, but per-match callbacks, set GC, and flowtable cleanup have nothing. That's where most of the recent netfilter CVEs actually fire. 5. Crypto subsystem + io_uring per-opcode: crypto/ has zero LSM hooks. -- Thanks, Sasha