[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20260205172521.GN2328995@ziepe.ca>
Date: Thu, 5 Feb 2026 13:25:21 -0400
From: Jason Gunthorpe <jgg@...pe.ca>
To: Konstantin Taranov <kotaranov@...rosoft.com>
Cc: Konstantin Taranov <kotaranov@...ux.microsoft.com>,
Shiraz Saleem <shirazsaleem@...rosoft.com>,
Long Li <longli@...rosoft.com>, "leon@...nel.org" <leon@...nel.org>,
"linux-rdma@...r.kernel.org" <linux-rdma@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH rdma-next v2 1/1] RDMA/mana_ib: return PD number to the
user
On Thu, Feb 05, 2026 at 04:35:44PM +0000, Konstantin Taranov wrote:
>
> > On Thu, Feb 05, 2026 at 04:13:54AM -0800, Konstantin Taranov wrote:
> > > From: Konstantin Taranov <kotaranov@...rosoft.com>
> > >
> > > Implement returning to userspace applications PDNs of created PDs.
> > > The PDN is used by applications that build work requests outside of
> > > the rdma-core code base. The PDN is used to build work requests that
> > > require additional PD isolation checks. The requests can fit only 16 bit
> > PDNs.
> > > Allow users to request short PDNs which are 16 bits.
> >
> > What?
> >
> > PDN is protected information it should never be given to the HW directly
> > from userspace.
> >
> > How can this possibly be secure?
>
> As far as I know, it is secure as classical PD check for WQ exists and it is just some
> additional requirement to mention PDN in a request.
If all you are doing is sending a PDN in a WQ that must always match
that PDN that the WQ already has then I would agree that is OK.
But a completely nonsensical thing to do - to the point I'm skeptical
that it is actually being validated ???
> I am not the one who created this requirement to mention PDN in the
> request, but I got an ask to expose that since some vendors do that,
> and there were no security concerns (see struct mlx5dv_pd from
> mlx5dv_init_obj()).
That's different, that is going through a FW path and mlx5 has a UID
mechanism to link the permitted PDN to the user making the request.
> It seems is not a concern when
> the PDN is set from user-space into the address vector (see fill_ud_av() from hns,
> mlx4_create_ah(). and mthca_alloc_av()). As far as I understand, the use-case
> aimed here is similar to address vectors.
All these AH cases all end up with checks in SW or HW that the PDN is
valid for the context. What you are describing could be real, but is
so hard to accept that I'm going to ask you to strongly verify it and
document all this in the commit message.
Jason
Powered by blists - more mailing lists