From owner-freebsd-net@freebsd.org Fri Jul 10 00:06:47 2020 Return-Path: Delivered-To: freebsd-net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 223E735A13E for ; Fri, 10 Jul 2020 00:06:47 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [IPv6:2a01:4f8:c2c:26d8::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4B2td16kHBz3ZZV; Fri, 10 Jul 2020 00:06:45 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [IPv6:2a03:3100:c:13:0:0:0:5]) by hz.grosbein.net (8.15.2/8.15.2) with ESMTPS id 06A06bCY090175 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 10 Jul 2020 00:06:39 GMT (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: bc979@lafn.org Received: from [10.58.0.10] (dadvw [10.58.0.10]) by eg.sd.rdtc.ru (8.15.2/8.15.2) with ESMTPS id 06A06WYn093712 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 10 Jul 2020 07:06:32 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: making SCTP loadable and removing it from GENERIC To: Doug Hardie , Mark Johnston References: <20200709151300.GC8947@raichu> <63F4446F-DECF-4DE8-99CA-EC8755A5D4A1@mail.sermon-archive.info> Cc: freebsd-net@freebsd.org, tuexen@freebsd.org From: Eugene Grosbein Message-ID: <44d21cf7-e154-f7f4-12ee-6dce1c3f9a63@grosbein.net> Date: Fri, 10 Jul 2020 07:06:22 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <63F4446F-DECF-4DE8-99CA-EC8755A5D4A1@mail.sermon-archive.info> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=0.3 required=5.0 tests=BAYES_00,LOCAL_FROM, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.2 X-Spam-Report: * -2.3 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * -0.0 SPF_PASS SPF: sender matches SPF record * 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record * 2.6 LOCAL_FROM From my domains X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on hz.grosbein.net X-Rspamd-Queue-Id: 4B2td16kHBz3ZZV X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=permerror (mx1.freebsd.org: domain of eugen@grosbein.net uses mechanism not recognized by this client) smtp.mailfrom=eugen@grosbein.net X-Spamd-Result: default: False [-1.29 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.44)[-0.443]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-0.93)[-0.927]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[grosbein.net]; NEURAL_SPAM_SHORT(0.18)[0.177]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; R_SPF_PERMFAIL(0.00)[empty SPF record]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/29, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2020 00:06:47 -0000 10.07.2020 2:44, Doug Hardie wrote: >> On 9 July 2020, at 08:13, Mark Johnston 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 me how to fix the issue? I am not likely to remember about this 6 months from now. If an application starts with superuser privileges (as root), it is allowed to perform the check and load the module if needed: int modload(const char *name) { if (modfind(name) < 0) if (kldload(name) < 0 || modfind(name) < 0) { warn("%s: module not found", name); return 0; } return 1; } ... modload("sctp"); This works for both cases of sctp built into the kernel and already loaded as module. Alternatively, if an application already has rc.d startup script, you don't even need to change application source code but add required_modules="sctp" to the script, see rc.subr(8), then sctp.ko would be loaded automagically if it was not loaded yet and not present in the kernel.