From: Jason Gunthorpe <jgg@nvidia.com>
To: Parav Pandit <parav@nvidia.com>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>,
"Serge E. Hallyn" <serge@hallyn.com>,
"linux-rdma@vger.kernel.org" <linux-rdma@vger.kernel.org>,
"linux-security-module@vger.kernel.org"
<linux-security-module@vger.kernel.org>,
Leon Romanovsky <leonro@nvidia.com>
Subject: Re: [PATCH] RDMA/uverbs: Consider capability of the process that opens the file
Date: Thu, 24 Apr 2025 11:13:47 -0300 [thread overview]
Message-ID: <20250424141347.GS1648741@nvidia.com> (raw)
In-Reply-To: <CY8PR12MB7195D5ED46D8E920A5281393DC852@CY8PR12MB7195.namprd12.prod.outlook.com>
On Thu, Apr 24, 2025 at 09:08:17AM +0000, Parav Pandit wrote:
> > Since ib_device has a namespace and ufile is tied to a ib_device, can we ever
> > have a situation where the ib_device has a different namespace than the
> > ufile's? This would mean we changed the namespace of the ib_device, and
> > IIRC, that means we revoked/disassociated the ufile? So the answer is no?
> > This means #4 and #5 are the same thing.
> >
> Right.
>
> > Can a uobject affiliated netdev have a different namespace than the
> > ib_device?
> When a uobject when created, it is not affiliated to netdev.
I'm asking about when it does have a netdev. When you create/modify a
QP and give it a gid index, for instance.
> > The netdevs arise from the gid table, and the gid table population
> > should strictly follow the ib_device namespace, yes?
> I wish it this way, but unfortunately, rdma still have ancient
> shared mode for example single rdma device + macvlan. Until that is
> deprecated, let the gid table entry's netdev drives the QP modify as
> done today.
I have been ignoring shared mode in all of this analysis. I don't
think you can make sane statements about container security in shared
mode.
> > Can current have a different namespace than the ib_device? I guess yes, the
> > FD can be passed around. However this would mean that the FD caller should
> > not be able to get any gid table handles as none of its ifindexes will work. So
> > #1 is != #3/#4/#5
>
> Well, it can pass the fd after the ifindex is resolved (i.e. after modify_qp).
> If fd is passed before modify qp in different net ns, its can get access too because rdma device got shared.
That's all fine. The uobject retains its affiliated netdev.
> But that is the case with raw socket too. The difference is, every
> send() call checks the ifindex, vs here its checked when raw qp is
> created.
Also I think fine
> We can add the additional check in the sysfs and in modify qp, but
> very long ago (2019), we envisioned that users should use only the
> exclusive mode. And hence, those checks were not added.
I think we should ignore shared mode, it doesn't work sanely with
namespaces.
> > What other NS users are there?
> Incoming rx IB mad packets are looked up in the GID's attached netdev's net ns.
Ultimately a GID index should not be delivered to a userspace that
does not have that GID index in the objects affiliated net namespace.
I wonder if we are missing some validation here
> In-kernel ulps (nfs, smc) do not seem to have the interest, but they
> do not created uobjects nor they access any uverbs fd.
IIRC we have open issues with NFS/SRP/etc and namespaces, the kernel
ULP doesn't have a way to use a namespace?
Jason
next prev parent reply other threads:[~2025-04-24 14:13 UTC|newest]
Thread overview: 58+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-13 5:08 [PATCH] RDMA/uverbs: Consider capability of the process that opens the file Parav Pandit
2025-03-17 19:31 ` Jason Gunthorpe
2025-03-18 3:43 ` Parav Pandit
2025-03-18 11:20 ` Jason Gunthorpe
2025-03-18 12:30 ` Parav Pandit
2025-03-18 12:44 ` Jason Gunthorpe
2025-03-18 20:00 ` Eric W. Biederman
2025-03-18 22:57 ` Jason Gunthorpe
2025-04-04 14:53 ` Parav Pandit
2025-04-04 15:13 ` Jason Gunthorpe
2025-04-06 14:15 ` Serge E. Hallyn
2025-04-07 11:16 ` Parav Pandit
2025-04-07 14:46 ` sergeh
2025-04-20 12:30 ` Parav Pandit
2025-04-20 13:41 ` Serge E. Hallyn
2025-04-20 17:31 ` Parav Pandit
2025-04-07 16:12 ` Jason Gunthorpe
2025-04-08 14:44 ` Eric W. Biederman
2025-04-21 3:13 ` Serge E. Hallyn
2025-04-21 11:04 ` Parav Pandit
2025-04-21 13:00 ` Serge E. Hallyn
2025-04-21 13:33 ` Parav Pandit
2025-04-21 17:22 ` Serge E. Hallyn
2025-04-22 12:46 ` Jason Gunthorpe
2025-04-22 13:14 ` Serge E. Hallyn
2025-04-22 16:11 ` Jason Gunthorpe
2025-04-22 16:29 ` Serge E. Hallyn
2025-04-23 12:41 ` Parav Pandit
2025-04-23 14:46 ` Jason Gunthorpe
2025-04-23 15:43 ` Eric W. Biederman
2025-04-23 15:56 ` Parav Pandit
2025-04-23 16:45 ` Jason Gunthorpe
2025-04-24 9:08 ` Parav Pandit
2025-04-24 14:13 ` Jason Gunthorpe [this message]
2025-04-25 13:14 ` Parav Pandit
2025-04-25 13:29 ` Jason Gunthorpe
2025-04-25 13:54 ` Parav Pandit
2025-04-25 14:06 ` Serge E. Hallyn
2025-04-25 15:05 ` Parav Pandit
2025-04-25 15:29 ` Serge E. Hallyn
2025-04-25 13:59 ` Serge E. Hallyn
2025-04-25 14:01 ` Serge E. Hallyn
2025-04-25 14:24 ` Jason Gunthorpe
2025-04-25 15:06 ` Serge E. Hallyn
2025-04-25 15:27 ` Parav Pandit
2025-04-25 15:46 ` Eric W. Biederman
2025-04-25 16:16 ` Parav Pandit
2025-04-25 15:32 ` Eric W. Biederman
2025-04-25 16:21 ` Jason Gunthorpe
2025-04-25 17:34 ` Eric W. Biederman
2025-04-25 18:20 ` Parav Pandit
2025-04-25 18:35 ` Jason Gunthorpe
2025-04-27 14:30 ` Serge E. Hallyn
2025-04-28 17:03 ` Eric W. Biederman
2025-04-29 3:56 ` Eric W. Biederman
2025-04-29 10:39 ` Parav Pandit
2025-04-30 3:34 ` Eric W. Biederman
2025-04-30 12:14 ` Parav Pandit
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=20250424141347.GS1648741@nvidia.com \
--to=jgg@nvidia.com \
--cc=ebiederm@xmission.com \
--cc=leonro@nvidia.com \
--cc=linux-rdma@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=parav@nvidia.com \
--cc=serge@hallyn.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.