Date: Fri, 10 Jul 2020 11:39:38 +0200 From: Michael Tuexen <tuexen@freebsd.org> To: Eugene Grosbein <eugen@grosbein.net> Cc: Doug Hardie <bc979@lafn.org>, Mark Johnston <markj@freebsd.org>, freebsd-net@freebsd.org Subject: Re: making SCTP loadable and removing it from GENERIC Message-ID: <4B6A707F-88C4-43B8-96BF-24BC32E2C9A9@freebsd.org> In-Reply-To: <44d21cf7-e154-f7f4-12ee-6dce1c3f9a63@grosbein.net> References: <20200709151300.GC8947@raichu> <63F4446F-DECF-4DE8-99CA-EC8755A5D4A1@mail.sermon-archive.info> <44d21cf7-e154-f7f4-12ee-6dce1c3f9a63@grosbein.net>
next in thread | previous in thread | raw e-mail | index | archive | help
> On 10. Jul 2020, at 02:06, Eugene Grosbein <eugen@grosbein.net> wrote:
>=20
> 10.07.2020 2:44, Doug Hardie wrote:
>=20
>>> On 9 July 2020, at 08:13, Mark Johnston <markj@freebsd.org> wrote:
>>>=20
>>> Hi,
>>>=20
>>> 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.
>>>=20
>>> 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.
>>>=20
>>> 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.
>>>=20
>>> I am wondering if anyone has any objections to or concerns about =
this
>>> proposal. Any feedback is appreciated.
>>=20
>> 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.
>=20
> If an application starts with superuser privileges (as root), it is =
allowed to perform the check
> and load the module if needed:
>=20
> 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");
>=20
> This works for both cases of sctp built into the kernel and already =
loaded as module.
Hi Eugene,
you are completely right. However, it requires that the program needs to =
run
with root privileges just to be able to communicate.
In the context of userland stack, this is one of the most important =
issues.
In case of SCTP, this is needed to open a raw socket to send/recv SCTP =
packets.
This is one of the reasons why you use UDP encapsulation...
Best regards
Michael
>=20
> Alternatively, if an application already has rc.d startup script, you =
don't even need to change
> application source code but add required_modules=3D"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.
Interesting, I did not know that. Thanks for sharing.
Best regards
Michael
>=20
>=20
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4B6A707F-88C4-43B8-96BF-24BC32E2C9A9>