[dpdk-dev] thoughts on DPDK after a few days of reading sources

Alejandro Lucero alejandro.lucero at netronome.com
Thu Feb 11 12:58:31 CET 2016


Hi Seth,

I do not know if you and Ubuntu know about the kernel VFIO no-iommu mode
which DPDK will use in the future (then getting rid of UIO drives).

This implies distributions enabling that kernel VFIO mode which is not
enable by default as it is a security issue.

It would be good to know which is the Ubuntu position regarding this issue
and if there are any date or plan for supporting this.

Thanks

On Thu, Feb 11, 2016 at 7:58 AM, Thomas Monjalon <thomas.monjalon at 6wind.com>
wrote:

> Hi,
>
> 2016-02-10 19:05, Seth Arnold:
> > I've taken some notes while reading the sources; I'm sharing them in the
> > hopes that it's useful: on the one hand my fresh eyes may spot things
> that
> > you've overlooked, on the other hand your familiarity with the code means
> > that you're better suited to judge what I've found.
>
> Thanks for taking time and sharing, it's very valuable.
>
> > - shellcheck reports extensive cases of forgotten quotes to prevent word
> >   splitting or globbing, potentially unused variables, error-prone printf
> >   formatting. The scripts that are going to be used at runtime should be
> >   fixed:
> >   - ./debian/dpdk-init
> >   - ./debian/dpdk.init
>
> These files are not in the tree. Should they?
>
> > - ./drivers/net/cxgbe/cxgbe_ethdev.c eth_cxgbe_dev_init() memory leak in
> >   out_free_adapter: that doesn't free adapter
> > - ./drivers/net/virtio/virtio_ethdev.c virtio_set_multiple_queues() calls
> >   virtio_send_command(), which performs:
> >   memcpy(vq->virtio_net_hdr_mz->addr, ctrl, sizeof(struct
> virtio_pmd_ctrl));
> >   This copies a potentially huge amount of uninitialized data into ->addr
> >   because the struct virtio_pmd_ctrl ctrl was not zeroed before being
> >   passed. How much of this data leaves the system? Does this require a
> >   CVE?
>
> We are not used to open a CVE.
>
> [...]
> >   It's nearly impossible to solve issues without error reporting. Good
> >   error reporting saves admins time and money.
>
> Until now, the errors were reported on the list and most often fixed
> quickly.
> While I agree we need a more formal process (a bug tracker), I think we
> must
> be noticed of new bugs on the mailing list.
> Since nobody was against the bugzilla proposal, a deployment will be
> planned.
>         http://dpdk.org/ml/archives/dev/2015-August/023012.html
>


More information about the dev mailing list