On Thu, 9 Jun 2022 10:07:28 +0800 fengchengwen <fengcheng...@huawei.com> wrote:
> On 2022/6/9 9:31, Stephen Hemminger wrote: > > On Thu, 9 Jun 2022 08:41:35 +0800 > > fengchengwen <fengcheng...@huawei.com> wrote: > > > >> [snip] > >> > >>> > >>> 4) Removal of KNI > >>> ----------------- > >>> > >>> There is no more maintainer for KNI. > >>> > >>> A progressive removal proposal was made: > >>> - add a message at runtime and/or compilation to announce deprecation > >>> - remove KNI example after 22.11 > >>> - remove lib + kmod from main repo for 23.11 > >> > >> We still use KNI in some business scenarios, and we want to maintain it in > >> this case. > > > > > > Why? > > The KNI module can be used in following scenarios: when the PF is taken over > by the DPDK, > some traffic needs to be transmitted through the kernel protocol stack, we > did have this > application scenario. > > If do not proactively maintain the KNI, security risks may occur. and this's > our starting point. What is wrong with TAP or virtio user for your application? KNI already is a security risk, it implicitly trusts userspace. > > > > >> > >> I recommend Huisong Li (lihuis...@huawei.com) as the new maintainer of the > >> KNI. > >> > >> He has been involved in the community for several years and submitted some > >> bugfix patches of KNI. > > > > KNI has several unfixable architectural issues. > > Could you show detail on this ? The fact that KNI calls user mode holding the RTNL mutex is only one of many places where KNI trusts user space. > > It would never pass a full upstream kernel review. > > > > I hope you realize the security impacts of this. > > Is there another option to act like KNI role ? Virtio user has been used as a better alternative. Bruce has recently taken on providing more documentation to make the transistion easier. One other option is you are free to take KNI on as a project that is maintained in parallel with DPDK (like TREX and some other packages).
