> > On Mon, Feb 19, 2018 at 05:46:43PM -0600, Steve Wise wrote: > > > > > > On Mon, Feb 19, 2018 at 05:17:29PM -0600, Steve Wise wrote: > > > > > > > > Wondering if keys should not be disclosed for security? > > > > > > > > > > > + RDMA_NLDEV_ATTR_RES_IOVA, /* u64 */ > > > > > > > > > > What is this supposed to be ? > > > > > > > > > > > > > It is the address or 64b value used in ib_sge.addr field of SGEs. > > mr.iova > > > > defines the beginning address of the MR. > > > > > > But kernel MRs can be fragmented, and we will have fragmented user > MRs > > > soon too I think. > > > > From the perspective of the peer application targeting specific areas in the > > MR, it is linear and contiguous, from mr.ivoa to mr.iova+mr.length-1. The > > pages backing that mr are not necessarily contiguous. > > > > > > > > > > We are talking about some MRs now with very complicated layouts, > and > > > > > support those in the kernel too. > > > > > > > > > > We already can't leak a kernel pointer here.. Not sure we should even > > > > > talk about pointers here at all.. > > > > > > > > It is part of what an application provides to register a MR. It will > > help > > > > in debugging an application to verify that the MR registered has the > > correct > > > > iova. > > > > > > Still, worried about security, exposing pointers is frowned on these > > > days. > > > > > > > I can remove IOVA, if that is your recommendation. > > Or you can require some CAP_ADMIN privilege to return IOVA among other > MR fields. I like this idea. Steve. -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
