From: Leon Romanovsky <leon@kernel.org>
To: Paul Moore <paul@paul-moore.com>
Cc: Jason Gunthorpe <jgg@ziepe.ca>,
Roberto Sassu <roberto.sassu@huaweicloud.com>,
KP Singh <kpsingh@kernel.org>,
Matt Bobrowski <mattbobrowski@google.com>,
Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
John Fastabend <john.fastabend@gmail.com>,
Andrii Nakryiko <andrii@kernel.org>,
Martin KaFai Lau <martin.lau@linux.dev>,
Eduard Zingerman <eddyz87@gmail.com>, Song Liu <song@kernel.org>,
Yonghong Song <yonghong.song@linux.dev>,
Stanislav Fomichev <sdf@fomichev.me>, Hao Luo <haoluo@google.com>,
Jiri Olsa <jolsa@kernel.org>, Shuah Khan <shuah@kernel.org>,
Saeed Mahameed <saeedm@nvidia.com>,
Itay Avraham <itayavr@nvidia.com>,
Dave Jiang <dave.jiang@intel.com>,
Jonathan Cameron <Jonathan.Cameron@huawei.com>,
bpf@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-kselftest@vger.kernel.org, linux-rdma@vger.kernel.org,
Chiara Meiohas <cmeiohas@nvidia.com>,
Maher Sanalla <msanalla@nvidia.com>,
linux-security-module@vger.kernel.org
Subject: Re: [PATCH v2 0/4] Firmware LSM hook
Date: Thu, 23 Apr 2026 16:05:01 +0300 [thread overview]
Message-ID: <20260423130501.GD172828@unreal> (raw)
In-Reply-To: <CAHC9VhSECYihup=tURo_Qk__xUdYYPkHgnz5CWA0BrRAkvwbog@mail.gmail.com>
On Wed, Apr 15, 2026 at 05:40:04PM -0400, Paul Moore wrote:
> On Wed, Apr 15, 2026 at 9:47 AM Jason Gunthorpe <jgg@ziepe.ca> wrote:
> > On Tue, Apr 14, 2026 at 04:27:58PM -0400, Paul Moore wrote:
> > > On Mon, Apr 13, 2026 at 7:19 PM Jason Gunthorpe <jgg@ziepe.ca> wrote:
> > > > On Mon, Apr 13, 2026 at 06:36:06PM -0400, Paul Moore wrote:
> > > > > On Mon, Apr 13, 2026 at 12:42 PM Jason Gunthorpe <jgg@ziepe.ca> wrote:
> > > > > > On Sun, Apr 12, 2026 at 09:38:35PM -0400, Paul Moore wrote:
>
> ...
<...>
> > > > > so that only the firmware would need to parse the request. If we
> > > > > wanted to adopt a secmark-esque approach, one could develop a second
> > > > > parsing mechanism that would be responsible for assigning a LSM label
> > > > > to the request, and then pass the firmware request to the LSM, but I
> > > > > do worry a bit about the added complexity associated with keeping the
> > > > > parser sync'd with the driver/fw.
> > > >
> > > > In practice it would be like iptables, the parser would be entirely
> > > > programmed by userspace and there is nothing to keep in sync.
> > >
> > > You've mentioned a few times now that the firmware/request will vary
> > > across not only devices, but firmware revisions too,
> >
> > I never said firmware revisions, part of the requirement is strong ABI
> > compatability in these packets.
>
> That was my mistake; it was Leon.
>
> Leon mentioned that different firmware revisions would have different
> parameters for a given opcode, and that one would need to inspect
> those parameters to properly filter the command. Is that not true, or
> am I misreading or misunderstanding Leon's comments?
>
> https://lore.kernel.org/all/20260310175759.GD12611@unreal
Right, I said that. The mlx5–FW interface is stable, but that does not
mean it can never change. The contract is that any upstream driver
release must continue to operate correctly with released firmware.
To support this, there are cases where the driver and firmware
negotiate during device initialization to determine whether a given
feature is supported and specific maibox fields are valid.
Thanks
next prev parent reply other threads:[~2026-04-23 13:05 UTC|newest]
Thread overview: 81+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-31 5:56 [PATCH v2 0/4] Firmware LSM hook Leon Romanovsky
2026-03-31 5:56 ` [PATCH v2 1/4] bpf: add firmware command validation hook Leon Romanovsky
2026-04-16 8:43 ` Matt Bobrowski
2026-03-31 5:56 ` [PATCH v2 2/4] selftests/bpf: add test cases for fw_validate_cmd hook Leon Romanovsky
2026-03-31 5:56 ` [PATCH v2 3/4] RDMA/mlx5: Externally validate FW commands supplied in DEVX interface Leon Romanovsky
2026-03-31 5:56 ` [PATCH v2 4/4] fwctl/mlx5: Externally validate FW commands supplied in fwctl Leon Romanovsky
2026-04-09 12:12 ` [PATCH v2 0/4] Firmware LSM hook Leon Romanovsky
2026-04-09 12:27 ` Roberto Sassu
2026-04-09 12:45 ` Leon Romanovsky
2026-04-09 21:04 ` Paul Moore
2026-04-12 9:00 ` Leon Romanovsky
2026-04-13 1:38 ` Paul Moore
2026-04-13 15:53 ` Leon Romanovsky
2026-04-13 16:42 ` Jason Gunthorpe
2026-04-13 17:36 ` Casey Schaufler
2026-04-13 19:09 ` Casey Schaufler
2026-04-13 22:36 ` Paul Moore
2026-04-13 23:19 ` Jason Gunthorpe
2026-04-14 17:05 ` Casey Schaufler
2026-04-14 19:09 ` Paul Moore
2026-04-14 20:09 ` Casey Schaufler
2026-04-14 20:44 ` Paul Moore
2026-04-14 22:42 ` Casey Schaufler
2026-04-15 21:03 ` Paul Moore
2026-04-15 21:21 ` Casey Schaufler
2026-04-14 20:27 ` Paul Moore
2026-04-15 13:47 ` Jason Gunthorpe
2026-04-15 21:40 ` Paul Moore
2026-04-17 19:17 ` Jason Gunthorpe
2026-04-21 0:58 ` Paul Moore
2026-04-24 14:36 ` Jason Gunthorpe
2026-04-24 20:59 ` Paul Moore
2026-04-24 22:13 ` Jason Gunthorpe
2026-04-23 14:09 ` Leon Romanovsky
2026-04-24 14:19 ` Jason Gunthorpe
2026-04-26 10:39 ` Leon Romanovsky
2026-04-23 13:05 ` Leon Romanovsky [this message]
-- strict thread matches above, loose matches on Subject: below --
2026-04-11 14:49 [PATCH rdma-next v2 00/15] RDMA: Introduce generic buffer descriptor infrastructure for umem Jiri Pirko
2026-04-11 14:49 ` [PATCH rdma-next v2 01/15] RDMA/core: " Jiri Pirko
2026-04-12 12:33 ` Michael Margolin
2026-04-13 8:32 ` Jiri Pirko
2026-04-13 16:02 ` Michael Margolin
2026-04-13 18:22 ` Jiri Pirko
2026-04-16 12:10 ` Michael Margolin
2026-04-16 13:34 ` Jiri Pirko
2026-04-21 12:50 ` Jason Gunthorpe
2026-04-21 12:52 ` Jason Gunthorpe
2026-04-22 10:32 ` Jiri Pirko
2026-04-22 16:30 ` Jason Gunthorpe
2026-04-21 13:46 ` Jason Gunthorpe
2026-04-22 11:33 ` Jiri Pirko
2026-04-22 14:06 ` Jiri Pirko
2026-04-22 16:51 ` Jason Gunthorpe
2026-04-23 13:08 ` Jiri Pirko
2026-04-23 15:08 ` Jason Gunthorpe
2026-04-11 14:49 ` [PATCH rdma-next v2 02/15] RDMA/uverbs: Push out CQ buffer umem processing into a helper Jiri Pirko
2026-04-21 13:25 ` Jason Gunthorpe
2026-04-22 10:56 ` Jiri Pirko
2026-04-22 16:32 ` Jason Gunthorpe
2026-04-11 14:49 ` [PATCH rdma-next v2 03/15] RDMA/uverbs: Integrate umem_list into CQ creation Jiri Pirko
2026-04-11 14:49 ` [PATCH rdma-next v2 04/15] RDMA/efa: Use umem_list for user CQ buffer Jiri Pirko
2026-04-11 14:49 ` [PATCH rdma-next v2 05/15] RDMA/mlx5: " Jiri Pirko
2026-04-11 14:49 ` [PATCH rdma-next v2 06/15] RDMA/bnxt_re: " Jiri Pirko
2026-04-11 14:49 ` [PATCH rdma-next v2 07/15] RDMA/mlx4: " Jiri Pirko
2026-04-11 14:49 ` [PATCH rdma-next v2 08/15] RDMA/uverbs: Remove legacy umem field from struct ib_cq Jiri Pirko
2026-04-11 14:49 ` [PATCH rdma-next v2 09/15] RDMA/uverbs: Verify all umem_list buffers are consumed after CQ creation Jiri Pirko
2026-04-11 14:49 ` [PATCH rdma-next v2 10/15] RDMA/uverbs: Integrate umem_list into QP creation Jiri Pirko
2026-04-11 14:49 ` [PATCH rdma-next v2 11/15] RDMA/mlx5: Use umem_list for QP buffers in create_qp Jiri Pirko
2026-04-11 14:49 ` [PATCH rdma-next v2 12/15] RDMA/uverbs: Add doorbell record buffer slot to CQ umem_list Jiri Pirko
2026-04-11 14:49 ` [PATCH rdma-next v2 13/15] RDMA/mlx5: Use umem_list for CQ doorbell record Jiri Pirko
2026-04-11 14:49 ` [PATCH rdma-next v2 14/15] RDMA/uverbs: Add doorbell record buffer slot to QP umem_list Jiri Pirko
2026-04-11 14:49 ` [PATCH rdma-next v2 15/15] RDMA/mlx5: Use umem_list for QP doorbell record Jiri Pirko
2026-04-25 6:04 [PATCH v2 0/2] RDMA/rxe: Fix per-netns UDP tunnel issues Kuniyuki Iwashima
2026-04-25 6:04 ` [PATCH v2 1/2] RDMA/rxe: Fix null-ptr-deref in kernel_sock_shutdown() Kuniyuki Iwashima
2026-04-25 15:47 ` David Ahern
2026-04-25 20:55 ` Kuniyuki Iwashima
2026-04-26 16:40 ` David Ahern
2026-04-25 21:25 ` Zhu Yanjun
2026-04-26 16:42 ` David Ahern
2026-04-25 6:04 ` [PATCH v2 2/2] RDMA/rxe: Fix up RCU usage for rxe_ns_pernet_sk6() Kuniyuki Iwashima
2026-04-25 21:26 ` Zhu Yanjun
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260423130501.GD172828@unreal \
--to=leon@kernel.org \
--cc=Jonathan.Cameron@huawei.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=cmeiohas@nvidia.com \
--cc=daniel@iogearbox.net \
--cc=dave.jiang@intel.com \
--cc=eddyz87@gmail.com \
--cc=haoluo@google.com \
--cc=itayavr@nvidia.com \
--cc=jgg@ziepe.ca \
--cc=john.fastabend@gmail.com \
--cc=jolsa@kernel.org \
--cc=kpsingh@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=linux-rdma@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=martin.lau@linux.dev \
--cc=mattbobrowski@google.com \
--cc=msanalla@nvidia.com \
--cc=paul@paul-moore.com \
--cc=roberto.sassu@huaweicloud.com \
--cc=saeedm@nvidia.com \
--cc=sdf@fomichev.me \
--cc=shuah@kernel.org \
--cc=song@kernel.org \
--cc=yonghong.song@linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox