From owner-freebsd-net@freebsd.org Thu Jul 9 20:10:50 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 C920D355181 for ; Thu, 9 Jul 2020 20:10:50 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-qt1-x841.google.com (mail-qt1-x841.google.com [IPv6:2607:f8b0:4864:20::841]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4B2nNn5hXnz4Ytn; Thu, 9 Jul 2020 20:10:49 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-qt1-x841.google.com with SMTP id w27so2673060qtb.7; Thu, 09 Jul 2020 13:10:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=mFGYMg2wzSSFxIKAWLpbQwjf3SCuFxu+TV5U45sURoE=; b=E7XwRetHcfiF+rqeG+z9rB6u9uoaRrHt1Iziz5uPZe45dVWqCQK80CT6u86T5Ql9xu oqruKZzSr2hi/oIIY1KwYjSC25DEMXecvP+1ErBYN2S5ZXa20PcGsh0JwDWHjelPmj7f 2HbyrgSrLlUpW8jDrD4bNMIUhEjj0TxrWrAc4R/fpJNWToOfNGIG6HxK10ZQWqKyPWpG qIFUXTHCuDh/jxweIz67mOdj1SSwCtzf4bfEKXMsRbc/dNLTXBu35LtiSfs732sO6mrk 921DGgym9ApqW4jGo3Rj23Zv1QHF8AILlOzHmz2o356g/Us6Rl2zowzooX3cveaAealb McQw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to; bh=mFGYMg2wzSSFxIKAWLpbQwjf3SCuFxu+TV5U45sURoE=; b=W8OApaqd03AhdGGS6EBRqUebCYUnZcuwmyipcDoDeOr5YKbAYqUSsaKZq2Kzb4m9Nf Wbu2axlxeTgRFu33KFv/KldM8F1o6QPbHEOZot/WNoSZUTkwlFy7Yw4RfC78BeGXggBt CRs47wETyU3EWhPxMooVdmxNlrvglKZtpxq/LMuuYXlL6UgimJThpyQs6o/NRBEIH/6P lbd0PtiT7+bd8nNu85B8vYphhw9/JIx16xS2TZV1v35xKSrbkLhyU4i7287CO+5B9790 kzsfYhoeD5R5b2H/iraGVvkzUqDXDcsEZKnalCYfJOlThj/qP+iodd0obuPc7t2G8qRg eQ3w== X-Gm-Message-State: AOAM531YwMAEyKn4vfW+ZTxHRpJxZdiv+/8+xszl+6DiBoA0DZzxzH2r Z9LWzkDIlvY9uGnqSZQmw5ld09gKfzk= X-Google-Smtp-Source: ABdhPJwYfeCIBtD73YsNSdY7HD+kBOhEFZv2qAIAjAZr0utmLF2ccKOuL6i4TzhJD8kXr5p388terw== X-Received: by 2002:aed:238d:: with SMTP id j13mr63106909qtc.220.1594325447539; Thu, 09 Jul 2020 13:10:47 -0700 (PDT) Received: from raichu (toroon0560w-lp130-14-174-91-9-204.dsl.bell.ca. [174.91.9.204]) by smtp.gmail.com with ESMTPSA id v28sm4493719qkv.31.2020.07.09.13.10.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 09 Jul 2020 13:10:46 -0700 (PDT) Sender: Mark Johnston Date: Thu, 9 Jul 2020 16:10:44 -0400 From: Mark Johnston To: Doug Hardie Cc: freebsd-net@freebsd.org, tuexen@freebsd.org Subject: Re: making SCTP loadable and removing it from GENERIC Message-ID: <20200709201044.GG8947@raichu> References: <20200709151300.GC8947@raichu> <63F4446F-DECF-4DE8-99CA-EC8755A5D4A1@mail.sermon-archive.info> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <63F4446F-DECF-4DE8-99CA-EC8755A5D4A1@mail.sermon-archive.info> X-Rspamd-Queue-Id: 4B2nNn5hXnz4Ytn X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=E7XwRetH; dmarc=none; spf=pass (mx1.freebsd.org: domain of markjdb@gmail.com designates 2607:f8b0:4864:20::841 as permitted sender) smtp.mailfrom=markjdb@gmail.com X-Spamd-Result: default: False [-1.79 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; NEURAL_HAM_MEDIUM(-0.97)[-0.967]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; NEURAL_HAM_LONG(-1.03)[-1.029]; MIME_GOOD(-0.10)[text/plain]; MID_RHS_NOT_FQDN(0.50)[]; DMARC_NA(0.00)[freebsd.org]; TO_DN_SOME(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; NEURAL_HAM_SHORT(-0.09)[-0.091]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::841:from]; FORGED_SENDER(0.30)[markj@freebsd.org,markjdb@gmail.com]; RECEIVED_SPAMHAUS_PBL(0.00)[174.91.9.204:received]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[markj@freebsd.org,markjdb@gmail.com]; 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: Thu, 09 Jul 2020 20:10:50 -0000 On Thu, Jul 09, 2020 at 12:44:25PM -0700, 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. 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.