Date: Wed, 15 May 2024 07:20:15 +0900 From: Tomoaki AOKI <junchoon@dec.sakura.ne.jp> To: Brooks Davis <brooks@freebsd.org> Cc: John Baldwin <jhb@freebsd.org>, Warner Losh <imp@bsdimp.com>, Konstantin Belousov <kostikbel@gmail.com>, henrichhartzer@tuta.io, Freebsd Arch <freebsd-arch@freebsd.org> Subject: Re: Disabling COMPAT_FREEBSD4/5/6/7/9 in default kernel configurations Message-ID: <20240515072015.cf36e92b38e22b267380318a@dec.sakura.ne.jp> In-Reply-To: <ZkJMEzZRtHfSvkVE@spindle.one-eyed-alien.net> References: <NxZrrMD--3-9@tuta.io> <Zj84HLfYP_Psx4Me@kib.kiev.ua> <CANCZdfpjYe%2B03hhyeFWM2yvhDkZFS7U02r72iO7JhYtcsg4zaw@mail.gmail.com> <1d4afad4-250b-4c1c-8206-279a92a26ae4@FreeBSD.org> <ZkJMEzZRtHfSvkVE@spindle.one-eyed-alien.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 13 May 2024 17:21:23 +0000 Brooks Davis <brooks@freebsd.org> 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 <kostikbel@gmail.com> > > > 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<n> 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<n> 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 <junchoon@dec.sakura.ne.jp>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20240515072015.cf36e92b38e22b267380318a>