[PATCH] RDMA/uverbs: Consider capability of the process that opens the file

[Jason Gunthorpe]

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