DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Zhou, Danny" <danny.zhou@intel.com>
To: Andre Richter <andre.o.richter@gmail.com>,
	Karmarkar Suyash <skarmarkar@sonusnet.com>,
	Stephen Hemminger <stephen@networkplumber.org>
Cc: "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] Running DPDK with Docker
Date: Thu, 2 Apr 2015 07:13:30 +0000	[thread overview]
Message-ID: <DFDF335405C17848924A094BC35766CF0AB3EF4A@SHSMSX104.ccr.corp.intel.com> (raw)
In-Reply-To: <CAKqeN2_OVVFmAanFq4R+LwVVbQ6V2Hagse2xEkb_25DPJ8VfXQ@mail.gmail.com>

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@dpdk.org] On Behalf Of Andre Richter
> Sent: Thursday, April 02, 2015 2:36 PM
> To: Karmarkar Suyash; Stephen Hemminger
> Cc: dev@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@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@networkplumber.org]
> > Sent: Thursday, April 02, 2015 12:12 AM
> > To: Karmarkar Suyash
> > Cc: dev@dpdk.org
> > Subject: Re: [dpdk-dev] Running DPDK with Docker
> >
> > On Wed, 1 Apr 2015 17:56:56 +0000
> > Karmarkar Suyash <skarmarkar@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?
> >

  reply	other threads:[~2015-04-02  7:14 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-01 17:56 Karmarkar Suyash
2015-04-01 18:41 ` Stephen Hemminger
2015-04-02  3:28   ` Karmarkar Suyash
2015-04-02  6:36     ` Andre Richter
2015-04-02  7:13       ` Zhou, Danny [this message]
2015-04-01 23:08 ` Zhou, Danny

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=DFDF335405C17848924A094BC35766CF0AB3EF4A@SHSMSX104.ccr.corp.intel.com \
    --to=danny.zhou@intel.com \
    --cc=andre.o.richter@gmail.com \
    --cc=dev@dpdk.org \
    --cc=skarmarkar@sonusnet.com \
    --cc=stephen@networkplumber.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).