On 06-Jan-19 23:30, Jason Gunthorpe wrote: > On Sun, Jan 06, 2019 at 03:33:15PM +0200, Gal Pressman wrote: > >>> Otherwise there can be use-after free style security bugs. >>> >>> Since the efa_dealloc_ucontext does nothing, and BAR pages are being >>> mapped, it must be wrong. >> >> Can you please elaborate? what would you like to see in dealloc_ucontext? > > Freeing bar page allocations. > >>> It kind of looks like it is trying to tie BAR allocation lifetime to >>> individual objects? >>> >>> .. and all of this is why one generally focuses on the ucontext as the >>> limit, as generally, allocating a ucontext implies allocating a BAR >>> page, and thus the number of ucontexts is strictly limited by the BAR >>> size. >> >> s/ucontext/PD/g is the case for EFA, our device is not aware of >> ucontext but PDs. The BAR "reservation" is there for the lifetime of >> the PD. > > Which is what I just said was wrong. It's different, I still can't see how it's wrong. Our device is responsible for the BAR reservations, not the driver. The device ties it to the lifetime of the object, as long as the object lives the mapping is valid. When the object is created the device responds with it's BAR offset that should be mmapped to the user. If the user tries to ring a doorbell of a destroyed QP, that's not going to work.
