From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 C6E1E125A9; Mon, 13 Apr 2026 15:53:36 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776095616; cv=none; b=dix1E8+no/Yv00CqE+12xxhLy1Tc1LMm5q1dPd7v84eHhircEjMyUxdwhW+EzRiSFPx1hrGjNqQiKAkim3+TbF2Iw6aQDKMt5m7i5jsXJQ/bOcP5HGYe6i0J3Xqf7Eo3/FjbkE+3sZUF3Fr3Pv8sVNbKKeoxpYqRspcssPR6ZFQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776095616; c=relaxed/simple; bh=9M6tnLgIr+sMqBYY17RTZRwcr2YkcNi64g6q6UG2hdk=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=B4QeJ3Fse7ZUlZRvHFYiAwiWiR1QZ4Ao3tyZC+Hd81uZ54QiiLIFxjpn4XgFR3UfkgBq4E+tbBA4IAC6+eRIoi5AxlwJ7mFfmthYaFDSne6AqLUvFpPxy4c3zhYNbCgR8d7EDbyjJf1UDFBfoYaG9Skx/IqugIE4rGlM2885FAI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=ia0sDvZ4; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="ia0sDvZ4" Received: by smtp.kernel.org (Postfix) with ESMTPSA id F00D0C2BCAF; Mon, 13 Apr 2026 15:53:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1776095616; bh=9M6tnLgIr+sMqBYY17RTZRwcr2YkcNi64g6q6UG2hdk=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=ia0sDvZ4lmIa/fXnarKKku6xXJW3V+56XzaeZOpO6F3X8Ow8pD6wXa3N/3VWNOAaj ybUrRO4+LWB/5UiKpAQ4KCdCijHpeH92xtAcIsSXadz4Mjdwsy6+q6BRwZwIRZuukC rOlAtExAFewHXIQ9FAu0e5DUTneN75JJM7i5S3d00aZi3kXvvwQSnxf9KvBEmlcmTd JIWQwF74SQOLwTJArhFb2WflOc5KaoUtx84BBU2DXw4Z8AmFmuiOPXOMlpp13767Th 4qOLCEHoEV9tnM0NFO2zR/uV3LdtOOzTFqT322eQxO1KOeIgxzYadv6TGqsVCZvUwF OMb79RWzbXHAQ== Date: Mon, 13 Apr 2026 18:53:32 +0300 From: Leon Romanovsky To: Paul Moore Cc: Roberto Sassu , KP Singh , Matt Bobrowski , Alexei Starovoitov , Daniel Borkmann , John Fastabend , Andrii Nakryiko , Martin KaFai Lau , Eduard Zingerman , Song Liu , Yonghong Song , Stanislav Fomichev , Hao Luo , Jiri Olsa , Shuah Khan , Jason Gunthorpe , Saeed Mahameed , Itay Avraham , Dave Jiang , Jonathan Cameron , bpf@vger.kernel.org, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, linux-rdma@vger.kernel.org, Chiara Meiohas , Maher Sanalla , linux-security-module@vger.kernel.org Subject: Re: [PATCH v2 0/4] Firmware LSM hook Message-ID: <20260413155332.GL21470@unreal> References: <20260331-fw-lsm-hook-v2-0-78504703df1f@nvidia.com> <20260409121230.GA720371@unreal> <2dd138a2ae87f90c55dbc3178d9c798294fd4450.camel@huaweicloud.com> <20260409124553.GB720371@unreal> <20260412090006.GA21470@unreal> 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 Sun, Apr 12, 2026 at 09:38:35PM -0400, Paul Moore wrote: > On Sun, Apr 12, 2026 at 5:00 AM Leon Romanovsky wrote: > > On Thu, Apr 09, 2026 at 05:04:24PM -0400, Paul Moore wrote: > > > On Thu, Apr 9, 2026 at 8:45 AM Leon Romanovsky wrote: > > > > On Thu, Apr 09, 2026 at 02:27:43PM +0200, Roberto Sassu wrote: > > > > > On Thu, 2026-04-09 at 15:12 +0300, Leon Romanovsky wrote: > > > > > > On Tue, Mar 31, 2026 at 08:56:32AM +0300, Leon Romanovsky wrote: > > ... > > > > > We implemented this approach in v1: > > > > https://patch.msgid.link/20260309-fw-lsm-hook-v1-0-4a6422e63725@nvidia.com > > > > and were advised to pursue a different direction. > > > > > > I'm assuming you are referring to my comments? If so, that isn't exactly what I said, > > > I mentioned at least one other option besides > > > going directly to BPF. Ultimately, it is your choice to decide how > > > you want to proceed, but to claim I advised you to avoid a LSM based > > > solution isn't strictly correct. > > > > Yes, this matches how we understood your comments: > > https://lore.kernel.org/all/20260311081955.GS12611@unreal/ > > > > In the end, the goal is to build something practical and avoid adding > > unnecessary complexity that brings no real benefit to users. > > > > > Regardless, looking at your v2 patchset, it looks like you've taken an > > > unusual approach of using some of the LSM mechanisms, e.g. LSM_HOOK(), > > > but not actually exposing a LSM hook with proper callbacks. > > > Unfortunately, that's not something we want to support. If you want > > > to pursue an LSM based solution, complete with a security_XXX() hook, > > > use of LSM_HOOK() macros, etc. then that's fine, I'm happy to work > > > with you on that. > > > > The issue is that the sentence below was the reason we did not merge v1 with v2: > > https://github.com/LinuxSecurityModule/kernel/blob/main/README.md#new-lsm-hooks > > "pass through implementations, such as the BPF LSM, are not eligible for > > LSM hook reference implementations." > > I can expand on that in a minute, but I'd like to return to your use > of the LSM_HOOK() macro and locating the hook within the BPF LSM as > that is the most concerning issue from my perspective. One should > only use the LSM_HOOK() macro and locate code within bpf_lsm.c if that > code is part of the BPF LSM, utilizing an LSM hook. Since this > patchset doesn't use an LSM hook or any part of the LSM framework, the > implementation choices seem odd and are not something we want to > support. As mentioned in my prior reply, you could do something very > similar though the use of a normal BPF hook similar to what was done > with the update_socket_protocol() BPF hook. > > There are multiple reasons why out-of-tree and pass through LSMs are > not considered eligible for reference implementations of LSM hooks. I > think is most relevant to this patchset is that an out-of-tree hook > implementation doesn't necessarily require a stable interface, and > without a stable interface it is impossible to make a generic API at > the LSM framework layer. As you mentioned previously, each vendor and > each firmware version brings the possibility of a new > format/interface, and while that may not be a problem for out-of-tree > code which is left to the user/admin to manage, it makes upstream > development difficult. I did mention at least one approach that might > be a possibility to enable upstream, in-tree support of this, but you > seem to prefer a BPF approach that doesn't require a well defined > format. > > > > However, if you've decided that your preferred > > > option is to create a BPF hook you should avoid using things like > > > LSM_HOOK() and locating your hook/code in bpf_lsm.c. > > > > We are not limited to LSM solution, the goal is to intercept commands > > which are submitted to the FW and "security" bucket sounded right to us. > > Yes, it does sound "security relevant", but without a well defined > interface/format it is going to be difficult to write a generic LSM to > have any level of granularity beyond a basic "load firmware" > permission. > > > > The good news is that there are plenty of other examples of BPF > > > plugable code that you could use as an example, one such thing is the > > > update_socket_protocol() BPF hook that was originally proposed as a > > > LSM hook, but moved to a dedicated BPF hook as we generally want to > > > avoid changing non-LSM kernel objects within the scope of the LSMs. > > > While your proposed case is slightly different, I think the basic idea > > > and mechanism should still be useful. > > > > > > https://lore.kernel.org/all/cover.1692147782.git.geliang.tang@suse.com > > > > Thanks > > Good luck on whatever you choose, and while I'm guessing it is > unlikely, if you do decide to pursue a LSM based solution please let > us know and we can work with you to try and find ways to make it work. Thanks a lot. We should know which direction we'll take in a week or two, once Chiara wraps up her internal commitments and returns to this series. I appreciate your help. Thanks > > -- > paul-moore.com >