making SCTP loadable and removing it from GENERIC

Michael Tuexen tuexen at freebsd.org
Thu Jul 9 20:00:20 UTC 2020



> On 9. Jul 2020, at 21:44, Doug Hardie <bc979 at lafn.org> wrote:
> 
>> On 9 July 2020, at 08:13, Mark Johnston <markj at freebsd.org> wrote:
>> 
>> Hi,
>> 
>> I spent some time working on making it possible to load the SCTP stack
>> as a kernel module, the same as we do today with IPSec.  There is one
>> patch remaining to be committed before that can be done in head.  One
>> caveat is that the module can't be unloaded, as some work is needed to
>> make this safe.  However, this obviously isn't a regression.
>> 
>> The work is based on the observations that:
>> 1) the in-kernel SCTP stack is not widely used (I know that the same
>>  code is used in some userland applications), and
>> 2) the SCTP stack is quite large, most FreeBSD kernel developers are
>>  unfamiliar with it, and bugs in it can easily lead to security holes.
>> 
>> Michael has done a lot of work to fix issues in the SCTP code,
>> particularly those found by syzkaller, but given that in-kernel SCTP has
>> few users (almost certainly fewer than IPSec), it seems reasonable to
>> require users to opt in to having an SCTP stack with a simple "kldload
>> sctp".  Thus, once the last patch is committed I would like to propose
>> removing "options SCTP" from GENERIC kernel configs in head, replacing
>> it with "options SCTP_SUPPORT" to enable sctp.ko to be loaded.
>> 
>> I am wondering if anyone has any objections to or concerns about this
>> proposal.  Any feedback is appreciated.
> 
> I have a number of systems using SCTP.  It is a key part of a distributed application.  As a user of SCTP, I have a slight objection to removing it from the kernel.  It would require me to remember when setting up a new system to enable that.  I am not likely to remember.  What is going to happen if you run an application that uses SCTP and the module is not loaded?  What will remind 
The socket() call would fail. What then happens depend on the error handling in
your application.
> me how to fix the issue?  I am not likely to remember about this 6 months from now.
I'm not sure, but I guess Mark is planning to MFC the changes to stable/12.
So you would test this when upgrading to 12.2, I guess.
I suggested to document what user have to do (assuming they read
UPGRADING and it gets documented there.

Best regards
Michael
> 
> -- Doug



More information about the freebsd-net mailing list