lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Fri, 10 Oct 2014 03:49:23 +0000 From: "Zhou, Danny" <danny.zhou@...el.com> To: David Miller <davem@...emloft.net> CC: "willemb@...gle.com" <willemb@...gle.com>, "john.fastabend@...il.com" <john.fastabend@...il.com>, "dborkman@...hat.com" <dborkman@...hat.com>, "fw@...len.de" <fw@...len.de>, "gerlitz.or@...il.com" <gerlitz.or@...il.com>, "hannes@...essinduktion.org" <hannes@...essinduktion.org>, "netdev@...r.kernel.org" <netdev@...r.kernel.org>, "Ronciak, John" <john.ronciak@...el.com>, "amirv@...lanox.com" <amirv@...lanox.com>, "eric.dumazet@...il.com" <eric.dumazet@...il.com> Subject: RE: [net-next PATCH v1 1/3] net: sched: af_packet support for direct ring access > -----Original Message----- > From: David Miller [mailto:davem@...emloft.net] > Sent: Wednesday, October 08, 2014 12:06 AM > To: Zhou, Danny > Cc: willemb@...gle.com; john.fastabend@...il.com; dborkman@...hat.com; fw@...len.de; gerlitz.or@...il.com; > hannes@...essinduktion.org; netdev@...r.kernel.org; Ronciak, John; amirv@...lanox.com; eric.dumazet@...il.com > Subject: Re: [net-next PATCH v1 1/3] net: sched: af_packet support for direct ring access > > From: "Zhou, Danny" <danny.zhou@...el.com> > Date: Tue, 7 Oct 2014 15:21:15 +0000 > > > Once qpairs split-off is done, the user space driver, as a slave > > driver, will re-initialize those queues completely in user space by > > using paddr(in the case of DPDK, vaddr of DPDK used huge pages are > > translated to paddr) to fill in the packet descriptors. As of > > security concern raised in previous discussion, the reason we > > think(BTW, correct me if I am wrong) af_packet is most suitable is > > because only user application with root permission is allowed to > > successfully split-off queue pairs and mmap a small window of PCIe > > I/O space to user space, so concern regarding "device can DMA > > from/to any arbitrary physical memory." is not that big. As all user > > space device drivers based on UIO mechanism has the same concern > > issue, VFIO adds protection but it is based on IOMMU which is > > specific to Intel silicons. > > Wait a second. > > If there is no memory protection performed I'm not merging this. > > I thought the user has to associate a fixed pool of memory to the > queueus, the kernel attaches that memory, and then the user cannot > modify the addresses _AT_ _ALL_. > > If the user can modify the addresses in the descriptors and make > the chip crap on random memory, this is a non-starter. > > Sorry. Fairly enough, we will manage to add memory protection in future versions. Several options are under investigation. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists