DPDK patches and discussions
 help / color / mirror / Atom feed
From: Stephen Hemminger <stephen@networkplumber.org>
To: "Walker, Benjamin" <benjamin.walker@intel.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] Running DPDK as an unprivileged user
Date: Thu, 29 Dec 2016 17:14:53 -0800	[thread overview]
Message-ID: <20161229171453.57a4326a@xeon-e3> (raw)
In-Reply-To: <1483044080.11975.1.camel@intel.com>

On Thu, 29 Dec 2016 20:41:21 +0000
"Walker, Benjamin" <benjamin.walker@intel.com> wrote:

> The first open question I have is whether DPDK should allow
> uio at all on recent (4.x) kernels. My current understanding
> is that there is no way to pin memory and hugepages can now
> be moved around, so uio would be unsafe. What does the
> community think here?

DMA access without IOMMU (ie UIO) is not safe from a security
point of view. A malicious app could program device (like Ethernet
NIC) to change its current privledge level in kernel memory.
Therefore ignore UIO as an option if you want to allow unprivileged
access.

But there are many many systems without working IOMMU. Not just broken
motherboards, but virtualization environments (Xen, Hyper-V, and KVM until
very recently) where IOMMU is no going to work.  In these environments,
DPDK is still useful where the security risks are known.

If kernel broke pinning of hugepages, then it is an upstream kernel bug.

> 
> My second question is whether the user should be allowed to
> mix uio and vfio usage simultaneously. For vfio, the
> physical addresses are really DMA addresses and are best
> when arbitrarily chosen to appear sequential relative to
> their virtual addresses. For uio, they are physical
> addresses and are not chosen at all. It seems that these two
> things are in conflict and that it will be difficult, ugly,
> and maybe impossible to resolve the simultaneous use of
> both.

Unless application is running as privileged user (ie root), UIO
is not going to work. Therefore don't worry about mixed environment.

  reply	other threads:[~2016-12-30  1:14 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-12-29 20:41 Walker, Benjamin
2016-12-30  1:14 ` Stephen Hemminger [this message]
2017-01-02 14:32   ` Thomas Monjalon
2017-01-02 19:47     ` Stephen Hemminger
2017-01-03 22:50       ` Walker, Benjamin
2017-01-04 10:11         ` Thomas Monjalon
2017-01-04 21:35           ` Walker, Benjamin
2017-01-04 11:39 ` Tan, Jianfeng
2017-01-04 21:34   ` Walker, Benjamin
2017-01-05 10:09     ` Sergio Gonzalez Monroy
2017-01-05 10:16       ` Sergio Gonzalez Monroy
2017-01-05 14:58         ` Tan, Jianfeng
2017-01-05 15:52     ` Tan, Jianfeng
2017-11-05  0:17       ` Thomas Monjalon
2017-11-27 17:58         ` Walker, Benjamin
2017-11-28 14:16           ` Alejandro Lucero
2017-11-28 17:50             ` Walker, Benjamin
2017-11-28 19:13               ` Alejandro Lucero

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=20161229171453.57a4326a@xeon-e3 \
    --to=stephen@networkplumber.org \
    --cc=benjamin.walker@intel.com \
    --cc=dev@dpdk.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).