Hi Alejandro, thanks for the heads up - to make sure I got your correctly I assume you refer to:
[1]: dpdk: http://dpdk.org/browse/dpdk/commit/?id=e61512e4066740847ced4a85ee9c3334b511468f [2]: kernel: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=033291eccbdb [3]: kernel: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=ae5515d66362b9d96cdcfce504567f0b8b7bd83e [4]: kenrel: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=03a76b60f8ba27974e2d252bc555d2c103420e15 It seems we will be shipping DPDK 2.2 and Kernel 4.4 with the next release (no commitment being made). [1] is not in DPDK 2.2, so it won't be supported right away. If it can be used without [1] I wouldn't have realized that yet. But also in the kernel it is not only disabled by default - in fact the code itself got removed [3] and only later back into 4.5 [4]. I guess, to really activate, exploit, test and eventually support it - it would be up to an explicit request to do so which can then be evaluated against the risks. IMHO I think we have to wait and see how it will be workin in DPDK >=16.x and Kernel >=4.5 this kind of referring to [3] "... so rather than support an unproven kernel interface revert it and revisit ...". Thanks for the heads up Alejandro, I didn't really think much about it before - I'll revisit it every now and then to see how development around it goes on. Christian Ehrhardt Software Engineer, Ubuntu Server Canonical Ltd On Thu, Feb 11, 2016 at 12:58 PM, Alejandro Lucero < alejandro.lucero at netronome.com> wrote: > 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 > > >
