[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZNUzW3X3P0JvL4nI@ziepe.ca>
Date: Thu, 10 Aug 2023 15:58:35 -0300
From: Jason Gunthorpe <jgg@...pe.ca>
To: Mina Almasry <almasrymina@...gle.com>
Cc: Christian König <christian.koenig@....com>,
netdev@...r.kernel.org, linux-media@...r.kernel.org,
dri-devel@...ts.freedesktop.org,
"David S. Miller" <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>,
Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
Jesper Dangaard Brouer <hawk@...nel.org>,
Ilias Apalodimas <ilias.apalodimas@...aro.org>,
Arnd Bergmann <arnd@...db.de>, David Ahern <dsahern@...nel.org>,
Willem de Bruijn <willemdebruijn.kernel@...il.com>,
Sumit Semwal <sumit.semwal@...aro.org>,
Hari Ramakrishnan <rharix@...gle.com>,
Dan Williams <dan.j.williams@...el.com>,
Andy Lutomirski <luto@...nel.org>, stephen@...workplumber.org,
sdf@...gle.com
Subject: Re: [RFC PATCH v2 00/11] Device Memory TCP
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?
Jason
Powered by blists - more mailing lists