From nobody Tue May 14 22:20:15 2024 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Vf9lw05xrz5L6cd for ; Tue, 14 May 2024 22:20:28 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from www121.sakura.ne.jp (www121.sakura.ne.jp [153.125.133.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Vf9ls2yz0z4Xtw; Tue, 14 May 2024 22:20:24 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of junchoon@dec.sakura.ne.jp designates 153.125.133.21 as permitted sender) smtp.mailfrom=junchoon@dec.sakura.ne.jp Received: from kalamity.joker.local (123-1-21-232.area1b.commufa.jp [123.1.21.232]) (authenticated bits=0) by www121.sakura.ne.jp (8.17.1/8.17.1/[SAKURA-WEB]/20201212) with ESMTPA id 44EMKG01063554; Wed, 15 May 2024 07:20:16 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) Date: Wed, 15 May 2024 07:20:15 +0900 From: Tomoaki AOKI To: Brooks Davis Cc: John Baldwin , Warner Losh , Konstantin Belousov , henrichhartzer@tuta.io, Freebsd Arch Subject: Re: Disabling COMPAT_FREEBSD4/5/6/7/9 in default kernel configurations Message-Id: <20240515072015.cf36e92b38e22b267380318a@dec.sakura.ne.jp> In-Reply-To: References: <1d4afad4-250b-4c1c-8206-279a92a26ae4@FreeBSD.org> Organization: Junchoon corps X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd14.0) List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@FreeBSD.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.46 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.76)[-0.762]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ip4:153.125.133.16/28]; ONCE_RECEIVED(0.10)[]; MIME_GOOD(-0.10)[text/plain]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_ONE(0.00)[1]; RCVD_VIA_SMTP_AUTH(0.00)[]; HAS_ORG_HEADER(0.00)[]; ARC_NA(0.00)[]; TO_DN_SOME(0.00)[]; ASN(0.00)[asn:7684, ipnet:153.125.128.0/18, country:JP]; FREEMAIL_CC(0.00)[freebsd.org,bsdimp.com,gmail.com,tuta.io]; MID_RHS_MATCH_FROM(0.00)[]; R_DKIM_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; DMARC_NA(0.00)[sakura.ne.jp]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arch@freebsd.org]; RCVD_TLS_LAST(0.00)[]; RCPT_COUNT_FIVE(0.00)[6] X-Rspamd-Queue-Id: 4Vf9ls2yz0z4Xtw On Mon, 13 May 2024 17:21:23 +0000 Brooks Davis wrote: > On Mon, May 13, 2024 at 09:59:34AM -0700, John Baldwin wrote: > > On 5/11/24 7:01 AM, Warner Losh wrote: > > > On Sat, May 11, 2024, 3:19???AM Konstantin Belousov > > > wrote: > > > > > > > On Sat, May 11, 2024 at 01:38:38AM +0200, henrichhartzer@tuta.io wrote: > > > > > In my opinion, if all goes well, it may be wise to remove the old code > > > > in the next major version. Could do the full list, or just FreeBSD 4 and 5 > > > > compatibility, for instance. Barring notable negative feedback, of course. > > > > > > > > Strongly disagree. You are breaking ABI compat for users, for what gain? > > > > > > > > I do not care about disabling options in GENERIC (but then they must appear > > > > in LINT). > > > > > > > > > > > > > This sums up my view as well. Fine to not be in GENERIC, but removal is a > > > bridge too far. > > > > Same here. > > > > However, what I haven't really seen anywhere in this thread is a clear > > articulation for _why_ to remove these options for GENERIC. The reasons I > > can think of for removing from GENERIC are: > > > > 1) Shrinking the size of .text in GENERIC. GENERIC is not MINIMAL, but it > > is also not KITCHENSINK. While there is some binary-only software around > > that requires older versions, I strongly suspect that it is a rare use > > case and requiring a custom kernel is not too large of an imposition on > > users who need that. > > I worry a bit that we'll see breakage if we don't include things in > GENERIC. That's especially true for the things that aren't the system > call entries. > > > 2) Reducing the attack surface available via system calls (which is what > > COMPAT_FREEBSD is mostly about). I suspect that the theoretical > > surface here is larger than the practical one, but it's not zero. > > I think making the system calls loadable wouldn't be a huge amount > of work and would limit the most obvious attack surface. For some > COMPAT_FREEBSD# cases this may be all of it. Others you might need > to add a COMPAT_SUPPORT_FREEBSD# which we might consider keeping in > GENERIC. Making that split would help us better understand the attack > surface. Hm, I've missed the point (attack surface). So if once syscalls becomes available as module, unattended autoload (as I described on my previous post) wouldn't be a good idea. Maybe providing MINIMAL kernel without old ABI/KBI support in conjunction with GENERIC kernel with current form could be better. And would need to allow selecting which kernel to be installed on bsdinstall (or upcoming GUI installer?). > > If there are in fact binary-only programs built against older releases that > > are widely used, then that might be a counter balance to the range of > > options removed from GENERIC. > > > > I think though that just removing from GENERIC does not mean we should axe > > the ports. misc/compatN need to stick around for the options to still work > > in a custom kernel, and they are very cheap to build (just tarring up > > binaries). Also, converting COMPAT_FREEBSD to modules is non-trivial. > > I tend to think that removing the ports has no benefit and we should > keep them around. > > -- Brooks I strongly suspect that there would be binaries (including libraries) for old ABI/KBI, which are never in the ports tree and the developers provided them no longer maintaining (even rebuilding for newer ABI/KBI) the codes, are running sanely in the wild. Assuming something like Bug211837 [1]. [1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211837 -- Tomoaki AOKI