making SCTP loadable and removing it from GENERIC

[Doug Hardie]

> On 9 July 2020, at 13:10, Mark Johnston <markj at freebsd.org> wrote:
> 
> On Thu, Jul 09, 2020 at 12:44:25PM -0700, Doug Hardie 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.
> 
> To be clear, with the proposed change SCTP can be loaded at boot by
> adding a single line: sctp_load="YES" to /boot/loader.conf, or
> kld_list="sctp" to /etc/rc.conf.  Also, the change will not be present
> in a release until 13.0 or possibly 12.2, which provides plenty of time,
> and the release notes will reflect the change.
> 
> I was really looking for objections pointing out that a dynamically
> loaded SCTP stack would prevent or inhibit some workflow.  Relying on
> being able to configure systems from memory rather than using a
> checklist or some automated configuration management does not seem to be
> a good reason for keeping SCTP in the kernel.
> 
>> What is going to happen if you run an application that uses SCTP and the module is not loaded?
> 
> An attempt to create an SCTP socket will fail with EPROTONOSUPPORT,
> "Protocol not supported".
> 
>> What will remind me how to fix the issue?  I am not likely to remember about this 6 months from now.
> 
> Hopefully "protocol not supported" is a sufficiently descriptive error
> message. 

Actually, the users of these systems would have no clue about that message.  All they would figure out is that the system is down and they can't do their job and bitch to the CEO.  I am going to assume that that error will be produced by the socket call and I have added code to check for it and email me if it occurs.  I believe that the only viable approach for us is the rc.conf solution as some of these systems are rhapsberry pi 3s which I understand don't use the loader.conf file.

One of the configurations we are considering is for each user to have their own Rhapsberry Pi and eliminate the central server.  All data is replicated between all the machines so there is no need for a central server anymore.  If I can make that work, it would be a large cost savings for my client.

-- Doug