[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID:
<DU8PR83MB0975317E888CD5A6A58E2E26B499A@DU8PR83MB0975.EURPRD83.prod.outlook.com>
Date: Thu, 5 Feb 2026 16:35:44 +0000
From: Konstantin Taranov <kotaranov@...rosoft.com>
To: Jason Gunthorpe <jgg@...pe.ca>, Konstantin Taranov
<kotaranov@...ux.microsoft.com>
CC: 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: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. 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()). 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.
- Konstantin
>
> Jason
Powered by blists - more mailing lists