Drop the "ipddp" module?
Adam Seering
adam at seering.org
Tue Dec 20 17:11:42 UTC 2016
Hi Seth,
Thanks for the reply!
It has bit-rotted and appears to no longer serve its intended function.
CentOS (among others) stopped compiling this module many years ago. Its
upstream maintainers have not been responsive on netdev for years and don't
seem to be taking patches. More importantly, it breaks a kernel interface
that its newer pure-userspace counterpart "MacIPGW" depends on even if
compiled as a module *and not loaded*.
As justification for these claims:
"ipddp" has a bug[1][2] such that, even when built as a module, part of it
gets compiled directly into the kernel and causes IP-over-DDP packets to get
silently dropped. The only workaround is to not compile the module at all.
I don't think that's true. handle_ip_over_ddp() is static to
net/appletalk_ddp.c which is part of the appletalk module when
CONFIG_ATALK=m. So it should not be present when the appletalk module is
not loaded. The kernel will request the module be loaded when a socket
is created for the AF_APPLETALK protocol family, if it hasn't already
been loaded.
Good point. (I'm new to the kernel's source code; I missed that net/appletalk/ddp.c was in fact part of the appletalk module.)
However, the DDP protocol itself is (I believe?) part of the appletalk module. My objective is to handle IP-over-DDP packets in userspace. So I believe I want to load appletalk but I don't want handle_ip_over_ddp() to do its thing. Do you see a way to achieve that when CONFIG_IPDDP is set? If so, that's all I need :-)
It could well be that I'm the only person in the world who cares about
this. I'm not entirely averse to maintaining my own kernel build. But this
is such an obvious bug, and I really do like letting the Ubuntu security
team keep my kernel up-to-date for me... If y'all don't want to accept this
change, got any alternative suggestions?
I'd suggest that we disable the module in zesty and see if anyone
complains. Were you hoping to get it disabled in earlier releases?
That sounds good to me.
Thanks,
Adam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/kernel-team/attachments/20161220/bad18d88/attachment.html>
More information about the kernel-team
mailing list