-----"Leon Romanovsky" <leon@xxxxxxxxxx> wrote: ----- >To: "Bernard Metzler" <BMT@xxxxxxxxxxxxxx> >From: "Leon Romanovsky" <leon@xxxxxxxxxx> >Date: 05/08/2019 04:22PM >Cc: "Jason Gunthorpe" <jgg@xxxxxxxx>, linux-rdma@xxxxxxxxxxxxxxx >Subject: Re: [PATCH v8 02/12] SIW main include file > >On Wed, May 08, 2019 at 02:06:05PM +0000, Bernard Metzler wrote: >> -----"Jason Gunthorpe" <jgg@xxxxxxxx> wrote: ----- >> >> >To: "Bernard Metzler" <BMT@xxxxxxxxxxxxxx> >> >From: "Jason Gunthorpe" <jgg@xxxxxxxx> >> >Date: 05/08/2019 03:08PM >> >Cc: "Leon Romanovsky" <leon@xxxxxxxxxx>, >linux-rdma@xxxxxxxxxxxxxxx >> >Subject: Re: [PATCH v8 02/12] SIW main include file >> > >> >On Wed, May 08, 2019 at 08:07:59AM +0000, Bernard Metzler wrote: >> >> >> >> Memory access keys and QP IDs are generated as random >> >> >> >> numbers, since both are exposed to the application. >> >> >> >> Since XArray is not designed for sparsely distributed >> >> >> >> id ranges, I am still in favor of IDR for these two >> >> >> >> resources. >> >> > >> >> >IDR and xarray have identical underlying storage so this is >> >nonsense >> >> > >> >> >No new idr's or radix tree users will be accepted into rdma.... >> >Use >> >> >xarray >> >> > >> >> Sounds good to me! I just came across that introductory video >from >> >Matthew, >> >> where he explicitly stated that xarray will be not very >efficient >> >if the >> >> indices are not densely clustered. But maybe this is all far >beyond >> >the >> >> 24bits of index space a memory key is in. So let me drop that >IDR >> >thing >> >> completely, while handling randomized 24 bit memory keys. >> > >> >xarray/idr is a poor choice to store highly unclustered random >data >> > >> >I'm not sure why this is a problem, shouldn't the driver be in >> >control >> >of mkey assignment? Just use xa_alloc_cyclic and it will be >> >sufficiently clustered to be efficient. >> > >> >> It is a recommendation to choose a hard to predict memory >> key (to make it hard for an attacker to guess it). From >> RFC 5040, sec 8.1.1: >> >> An RNIC MUST choose the value of STags in a way difficult to >> predict. It is RECOMMENDED to sparsely populate them over the >> full available range. > >Nice, security by obscurity, this recommendation is nonsense in real >life, >protection should be done by separating PDs and not by hiding stags. > Not sure about that one. Randomizing peer visible references of local protocol state isn't something invented just here. Think of TCP's ISN randomization etc. Maybe best, in the near future, I'll do some RB tree thing for more efficiency. >> >> Since I did not want to roll my own bug-prone key based lookup, >> I chose idr. If you tell me xarray is just as inefficient as >> idr for sparse index distributions, I'll take xarray. >> >> Thanks, >> Bernard. >> > >
