[dpdk-dev] Running DPDK with Docker

Zhou, Danny danny.zhou at intel.com
Thu Apr 2 09:13:30 CEST 2015


Container itself is not considered as a secured solution that could provide strict resource isolation which
VT could provide. Basically, we have 4 different configuration as below, you could pick most appropriate one
depending on usage scenarios.

1) VT + VFIO: supposed to be the most secured solution, but unfortunately VFIO cannot run in a VM unless 
either software IOMMU(at performance degradation cost) or nested Vt-d(unavailable on any architecture) hardware 
feature is enable.
2) VT + UIO: secured solution in both host(uio to drive VF on host) and VM(uio to driver a pass-through VF in a VM), but VT 
has overhead comparing to container which is basically native performance.
3) Container + VFIO: Container itself does not provide strict resource isolation even VFIO could avoid changed PMD to DMA
packets to arbitrary memory regions.
4) Container + UIO: least secured solution, but might fit NFV use cases in which it runs trusted L4-L7 virtualized service functions
rather than customer applications in containers.

> -----Original Message-----
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Andre Richter
> Sent: Thursday, April 02, 2015 2:36 PM
> To: Karmarkar Suyash; Stephen Hemminger
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] Running DPDK with Docker
> 
> The uio drivers are not secured by an iommu.
> Therefore, you could misuse the NIC to DMA read/write into any part of
> memory, e.g. reading or writing to memory of the host or other containers.
> 
> This is a security breach if you enable a container to do this by giving it
> access via uio, because you have them to isolate processes against each
> other in the first place.
> 
> VFIO uses iommus to protect against that, but you need capable hardware,
> e.g. Intel VT-d support on x86.
> 
> http://en.m.wikipedia.org/wiki/IOMMU
> 
> Cheers,
> Andre
> 
> Karmarkar Suyash <skarmarkar at sonusnet.com> schrieb am Do., 2. Apr. 2015 um
> 05:28:
> 
> > << igb_uio and rte_kni are unlikely to be accepted upstream since they
> > have intrinsic security problems.
> >
> > Can you use VFIO?>>
> >
> > Hi Stephen,
> >
> > Thanks for the reply. Can you please elaborate on the security
> > issue?Thanks.
> >
> > Regards
> > Suyash
> >
> > -----Original Message-----
> > From: Stephen Hemminger [mailto:stephen at networkplumber.org]
> > Sent: Thursday, April 02, 2015 12:12 AM
> > To: Karmarkar Suyash
> > Cc: dev at dpdk.org
> > Subject: Re: [dpdk-dev] Running DPDK with Docker
> >
> > On Wed, 1 Apr 2015 17:56:56 +0000
> > Karmarkar Suyash <skarmarkar at sonusnet.com> wrote:
> >
> > > Hi,
> > >
> > > Given the popularity of Docker it would be nice if we can run DPDK
> > inside a Docker container but the challenge is the igb_uio.ko and
> > rte_kni.ko kernel modules which need to be compiled with the exact kernel
> > source running on the host.  Are there ways to seamlessly run DPDK with
> > Docker? I came across an articles about running DPDK with Linux container
> > but still the requirement is to insert igb_uio. Any plans to make the
> > igb_uio and rte_kni modules as default modules of Linux source code or any
> > other better approaches/suggestions ? Thanks.
> > >
> > > http://dpdk.org/ml/archives/dev/2014-October/006373.html
> > > http://permalink.gmane.org/gmane.comp.networking.dpdk.devel/6479
> >
> > igb_uio and rte_kni are unlikely to be accepted upstream since they have
> > intrinsic security problems.
> >
> > Can you use VFIO?
> >


More information about the dev mailing list