On Thu, Aug 10, 2023 at 11:58 AM Jason Gunthorpe <jgg@xxxxxxxx> wrote: > > On Thu, Aug 10, 2023 at 11:44:53AM -0700, Mina Almasry wrote: > > > Someone will correct me if I'm wrong but I'm not sure netlink itself > > will do (sufficient) access control. However I meant for the netlink > > API to bind dma-bufs to be a CAP_NET_ADMIN API, and I forgot to add > > this check in this proof-of-concept, sorry. I'll add a CAP_NET_ADMIN > > check in netdev_bind_dmabuf_to_queue() in the next iteration. > > Can some other process that does not have the netlink fd manage to > recv packets that were stored into the dmabuf? > The process needs to have the dma-buf fd to receive packets, and not necessarily the netlink fd. It should be possible for: 1. a CAP_NET_ADMIN process to create a dma-buf, bind it using a netlink fd, then share the dma-buf with another normal process that receives packets on it. 2. a normal process to create a dma-buf, share it with a privileged CAP_NET_ADMIN process that creates the binding via the netlink fd, then the owner of the dma-buf can receive data on the dma-buf fd. 3. a CAP_NET_ADMIN creates the dma-buf and creates the binding itself and receives data. We in particular plan to use devmem TCP in the first mode, but this detail is specific to us so I've largely neglected from describing it in the cover letter. If our setup is interesting: the CAP_NET_ADMIN process I describe in #1 is a 'tcpdevmem daemon' which allocates the GPU memory, creates a dma-buf, creates an RX queue binding, and shares the dma-buf with the ML application(s) running on our instance. The ML application receives data on the dma-buf via recvmsg(). The 'tcpdevmem daemon' takes care of the binding but also configures RSS & flow steering. The dma-buf fd sharing happens over a unix domain socket. -- Thanks, Mina
